| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | "ldh(at)laurent-hasson(dot)com" <ldh(at)laurent-hasson(dot)com> |
| Cc: | Peter Geoghegan <pg(at)bowt(dot)ie>, David Rowley <dgrowleyml(at)gmail(dot)com>, Justin Pryzby <pryzby(at)telsasoft(dot)com>, "pgsql-performance(at)postgresql(dot)org" <pgsql-performance(at)postgresql(dot)org> |
| Subject: | Re: Big performance slowdown from 11.2 to 13.3 |
| Date: | 2021-07-28 03:15:52 |
| Message-ID: | 543673.1627442152@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-performance |
"ldh(at)laurent-hasson(dot)com" <ldh(at)laurent-hasson(dot)com> writes:
> One question that popped up in my head. hash_mem_multiplier is an upper-bound right: it doesn't reserve memory ahead of time correct? So there is no reason for me to spend undue amounts of time fine-tuning this parameter? If I have work_mem to 521MB, then I can set hash_mem_multiplier to 8 and should be OK. This doesn't mean that every query will consume 4GB of memory.
Yeah, I wouldn't sweat over the specific value. The pre-v13 behavior
was effectively equivalent to hash_mem_multiplier = infinity, so if
you weren't having any OOM problems before, just crank it up.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2021-07-28 03:31:17 | Re: Big performance slowdown from 11.2 to 13.3 |
| Previous Message | David G. Johnston | 2021-07-28 03:06:59 | Re: Big performance slowdown from 11.2 to 13.3 |