| Type: | real |
| Défaut: | 1 |
| Min: | 1 |
| Max: | 1000 |
| Contexte: | user |
| Redémarrer: | false |
| Depuis: | 13 |
Utilisé pour calculer la quantité maximale de mémoire que les opérations basées sur le hachage peuvent utiliser. La limite finale est déterminée en multipliant work_mem par hash_mem_multiplier. La valeur par défaut est 1.0, ce qui rend les opérations de hachage sujettes au même maximum quework_mem pour les opérations basées sur le tri.
Pensez à augmenter hash_mem_multiplier dans les environnements où l'utilisation de fichiers temporaires survient fréquemment, tout spécialement quand augmenter uniquement work_mem a pour résultat une pression mémoire trop importante (la pression mémoire prend typiquement la forme d'erreurs pour manque de mémoire). Une configuration de 1.5 ou 2.0 pourrait être efficace avec des charges de travail variées. Des configurations plus hautes (entre 2.0 et 8.0, voire encore plus) pourraient être plus efficaces dans les environnements où work_mem a déjà été augmenté à 40 Moi, voire plus.
Sur StackOverflow
Sur pgsql-hackers
- Some comment problem in nodeAgg.c
- Removing "long int"-related limit on hash table sizes
- Re: Removing "long int"-related limit on hash table sizes
- Re: Delegating superuser tasks to new security roles (Was: Granting control of SUSET gucs to non-superusers)
- Re: Hybrid Hash/Nested Loop joins and caching results from subplans
