Re: Big performance slowdown from 11.2 to 13.3 - Mailing list pgsql-performance

From Peter Geoghegan
Subject Re: Big performance slowdown from 11.2 to 13.3
Date
Msg-id CAH2-WzmftijCna_aY-HyCUfswwfPCC4d2HjKab1cxM0QCFrRUQ@mail.gmail.com
Whole thread Raw
In response to Re: Big performance slowdown from 11.2 to 13.3  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Big performance slowdown from 11.2 to 13.3  (Justin Pryzby <pryzby@telsasoft.com>)
Re: Big performance slowdown from 11.2 to 13.3  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-performance
On Thu, Jul 22, 2021 at 9:21 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Yeah, I should have said "2GB plus palloc slop".  It doesn't surprise
> me a bit that we seem to be eating another 20% on top of the nominal
> limit.

MAX_KILOBYTES is the max_val for the work_mem GUC itself, and has been
for many years. The function get_hash_mem() returns a work_mem-style
int that callers refer to as hash_mem -- the convention is that
callers pretend that there is a work_mem style GUC (called hash_mem)
that they must access by calling get_hash_mem().

I don't see how it's possible for get_hash_mem() to be unable to
return a hash_mem value that could be represented by work_mem
directly. MAX_KILOBYTES is an annoyingly low limit on Windows, where
sizeof(long) is 4. But that's nothing new.

-- 
Peter Geoghegan



pgsql-performance by date:

Previous
From: Justin Pryzby
Date:
Subject: Re: Big performance slowdown from 11.2 to 13.3
Next
From: Justin Pryzby
Date:
Subject: Re: Big performance slowdown from 11.2 to 13.3