RE: Big performance slowdown from 11.2 to 13.3
ldh@laurent-hasson.com <ldh@laurent-hasson.com>
From: "ldh@laurent-hasson.com" <ldh@laurent-hasson.com>
To: Peter Geoghegan <pg@bowt.ie>, Tom Lane <tgl@sss.pgh.pa.us>
Cc: Jeff Davis <pgsql@j-davis.com>, David Rowley <dgrowleyml@gmail.com>, Justin Pryzby <pryzby@telsasoft.com>, "pgsql-performance@postgresql.org" <pgsql-performance@postgresql.org>
Date: 2021-07-22T16:18:55Z
Lists: pgsql-performance
-----Original Message----- From: Peter Geoghegan <pg@bowt.ie> Sent: Thursday, July 22, 2021 12:14 To: Tom Lane <tgl@sss.pgh.pa.us> Cc: Jeff Davis <pgsql@j-davis.com>; ldh@laurent-hasson.com; David Rowley <dgrowleyml@gmail.com>; Justin Pryzby <pryzby@telsasoft.com>; pgsql-performance@postgresql.org Subject: Re: Big performance slowdown from 11.2 to 13.3 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. -- Peter Geoghegan I could execute that test and re-cluster against the index. But I believe that's already done? Let me check. Thank you, Laurent.
Commits
-
Get rid of artificial restriction on hash table sizes on Windows.
- b154ee63bb65 14.0 landed
- 2b8f3f5a7c0e 13.4 landed
- 28d936031a86 15.0 landed