Re: Big performance slowdown from 11.2 to 13.3
От | David Rowley |
---|---|
Тема | Re: Big performance slowdown from 11.2 to 13.3 |
Дата | |
Msg-id | CAApHDvqtORmfiEZnywZxui-CrdtmA4hfHaJfmjWm5iLq3TPxVw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Big performance slowdown from 11.2 to 13.3 (Peter Geoghegan <pg@bowt.ie>) |
Ответы |
RE: Big performance slowdown from 11.2 to 13.3
|
Список | pgsql-performance |
On Fri, 23 Jul 2021 at 04:14, Peter Geoghegan <pg@bowt.ie> wrote: > > On Thu, Jul 22, 2021 at 8:45 AM Tom Lane <tgl@sss.pgh.pa.us> wrote: > > That is ... weird. Maybe you have found a bug in the spill-to-disk logic; > > it's quite new after all. Can you extract a self-contained test case that > > behaves this way? > > I wonder if this has something to do with the way that the input data > is clustered. I recall noticing that that could significantly alter > the behavior of HashAggs as of Postgres 13. Isn't it more likely to be reaching the group limit rather than the memory limit? if (input_groups * hashentrysize < hash_mem * 1024L) { if (num_partitions != NULL) *num_partitions = 0; *mem_limit = hash_mem * 1024L; *ngroups_limit = *mem_limit / hashentrysize; return; } There are 55 aggregates on a varchar(255). I think hashentrysize is pretty big. If it was 255*55 then only 765591 groups fit in the 10GB of memory. David
В списке pgsql-performance по дате отправления: