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

  1. Get rid of artificial restriction on hash table sizes on Windows.