Re: Big performance slowdown from 11.2 to 13.3
От | Peter Geoghegan |
---|---|
Тема | Re: Big performance slowdown from 11.2 to 13.3 |
Дата | |
Msg-id | CAH2-WzmftijCna_aY-HyCUfswwfPCC4d2HjKab1cxM0QCFrRUQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Big performance slowdown from 11.2 to 13.3 (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Big performance slowdown from 11.2 to 13.3
Re: Big performance slowdown from 11.2 to 13.3 |
Список | 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 по дате отправления: