Re: Big performance slowdown from 11.2 to 13.3
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: David Rowley <dgrowleyml@gmail.com>
Cc: "ldh@laurent-hasson.com" <ldh@laurent-hasson.com>,
Peter Geoghegan <pg@bowt.ie>, Justin Pryzby <pryzby@telsasoft.com>,
"pgsql-performance@postgresql.org" <pgsql-performance@postgresql.org>
Date: 2021-07-22T16:21:38Z
Lists: pgsql-performance
David Rowley <dgrowleyml@gmail.com> writes: > On Fri, 23 Jul 2021 at 03:56, Tom Lane <tgl@sss.pgh.pa.us> wrote: >> So basically, we now have a hard restriction that hashaggs can't use >> more than INT_MAX kilobytes, or approximately 2.5GB, and this use case >> is getting eaten alive by that restriction. Seems like we need to >> do something about that. > Hmm, math check? 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. I think the right fix here is to remove the cap, which will require changing get_hash_mem to return double, and then maybe some cascading changes --- I've not looked at its callers. regards, tom lane
Commits
-
Get rid of artificial restriction on hash table sizes on Windows.
- b154ee63bb65 14.0 landed
- 2b8f3f5a7c0e 13.4 landed
- 28d936031a86 15.0 landed