From: | Peter Geoghegan <pg(at)bowt(dot)ie> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | David Rowley <dgrowleyml(at)gmail(dot)com>, "ldh(at)laurent-hasson(dot)com" <ldh(at)laurent-hasson(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-22 16:36:02 |
Message-ID: | CAH2-WzmftijCna_aY-HyCUfswwfPCC4d2HjKab1cxM0QCFrRUQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
On Thu, Jul 22, 2021 at 9:21 AM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Justin Pryzby | 2021-07-22 16:41:27 | Re: Big performance slowdown from 11.2 to 13.3 |
Previous Message | Justin Pryzby | 2021-07-22 16:35:56 | Re: Big performance slowdown from 11.2 to 13.3 |