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
- Re: Todo: Teach planner to evaluate multiple windows in the optimal order
- Re: Option to not use ringbuffer in VACUUM, using it in failsafe mode
- Re: Memory leak from ExecutorState context?
- Re: using memoize in in paralel query decreases performance
- Re: [PoC] Improve dead tuple storage for lazy vacuum