Re: Big performance slowdown from 11.2 to 13.3 - Mailing list pgsql-performance

From Tom Lane
Subject Re: Big performance slowdown from 11.2 to 13.3
Date
Msg-id 732367.1626910557@sss.pgh.pa.us
Whole thread Raw
In response to RE: Big performance slowdown from 11.2 to 13.3  ("ldh@laurent-hasson.com" <ldh@laurent-hasson.com>)
Responses RE: Big performance slowdown from 11.2 to 13.3  ("ldh@laurent-hasson.com" <ldh@laurent-hasson.com>)
List pgsql-performance
"ldh@laurent-hasson.com" <ldh@laurent-hasson.com> writes:
> My apologies... I thought this is what I had attached in my original email from PGADMIN. In any case, I reran from
thecommand line and here are the two plans. 

So the pain seems to be coming in with the upper hash aggregation, which
is spilling to disk because work_mem of '384MB' is nowhere near enough.
The v11 explain doesn't show any batching there, which makes me suspect
that it was using a larger value of work_mem.  (There could also be some
edge effect that is making v13 use a bit more memory for the same number
of tuples, which could lead it to spill when v11 had managed to scrape by
without doing so.)

So the first thing I'd try is seeing if setting work_mem to 1GB or so
improves matters.

The other thing that's notable is that v13 has collapsed out the CTE
that used to sit between the two levels of hashagg.  Now I don't know
of any reason that that wouldn't be a strict improvement, but if the
work_mem theory doesn't pan out then that's something that'd deserve
a closer look.  Does marking the WITH as WITH MATERIALIZED change
anything about v13's performance?

            regards, tom lane



pgsql-performance by date:

Previous
From: Peter Geoghegan
Date:
Subject: Re: Big performance slowdown from 11.2 to 13.3
Next
From: "ldh@laurent-hasson.com"
Date:
Subject: RE: Big performance slowdown from 11.2 to 13.3