Tom,
One question that popped up in my head. hash_mem_multiplier is an upper-bound right: it doesn't reserve memory ahead of
timecorrect? So there is no reason for me to spend undue amounts of time fine-tuning this parameter? If I have work_mem
to521MB, then I can set hash_mem_multiplier to 8 and should be OK. This doesn't mean that every query will consume 4GB
ofmemory.
Thank you,
Laurent.
-----Original Message-----
From: Tom Lane <tgl@sss.pgh.pa.us>
Sent: Sunday, July 25, 2021 14:08
To: ldh@laurent-hasson.com
Cc: Peter Geoghegan <pg@bowt.ie>; David Rowley <dgrowleyml@gmail.com>; Justin Pryzby <pryzby@telsasoft.com>;
pgsql-performance@postgresql.org
Subject: Re: Big performance slowdown from 11.2 to 13.3
"ldh@laurent-hasson.com" <ldh@laurent-hasson.com> writes:
> As a user of PG, we have taken pride in the last few years in tuning the heck out of the system and getting great
performancecompared to alternatives like SQLServer. The customers we work with typically have data centers and are
overwhelminglyWindows shops: we won the battle to deploy a complex operational system on PG vs SQLServer, but Linux vs
Windowswas still a bridge too far for many. I am surprised that this limitation introduced after V11 hasn't caused
issueselsewhere though.
Maybe it has, but you're the first to report the problem, or at least the first to report it with enough detail to
tracethe cause.
I've pushed a fix that removes the artificial restriction on work_mem times hash_mem_multiplier; it will be in next
month's13.4 release.
You'll still need to increase hash_mem_multiplier to get satisfactory performance on your workload, but at least it'll
bepossible to do that.
regards, tom lane
