On Fri, 3 Jun 2022 at 16:03, John Naylor <john.naylor@enterprisedb.com> wrote:
>
> On Fri, Jun 3, 2022 at 10:14 AM David Rowley <dgrowleyml@gmail.com> wrote:
> > 4. As I just demonstrated in [1], if anyone is caught by this and has
> > a problem, the work_mem size increase required seems very small to get
> > performance back to better than in PG14. I found that setting work_mem
> > to 64.3MB makes PG15 faster than PG14 for the problem case. If anyone
> > happened to hit this case and find the performance regression
> > unacceptable then they have a way out... increase work_mem a little.
>
> Since #4 is such a small lift, I'd be comfortable with closing the open item.
I also think that we should close off this open item for PG15. The
majority of cases are faster now and it is possible for anyone who
does happen to hit a bad case to raise work_mem by some fairly small
fraction.
I posted a WIP patch on [1] that we aim to get into PG16 to improve
the situation here further. I'm hoping the fact that we do have some
means to fix this for PG16 might mean we can leave this as a known
issue for PG15.
So far only Robert has raised concerns with this regression for PG15
(see [2]). Tom voted for leaving things as they are for PG15 in [3].
John agrees, as quoted above. Does anyone else have any opinion?
David
[1] https://www.postgresql.org/message-id/CAApHDvpjauCRXcgcaL6+e3eqecEHoeRm9D-kcbuvBitgPnW=vw@mail.gmail.com
[2] https://www.postgresql.org/message-id/CA+TgmoZoYxFBN+AEJGfjJCCbeW8MMkHfFVcC61kP2OncmeYDWA@mail.gmail.com
[3] https://www.postgresql.org/message-id/180278.1654009751@sss.pgh.pa.us
