Re: PG15 beta1 sort performance regression due to Generation context change

From: Andres Freund <andres(at)anarazel(dot)de>
To: "Jonathan S(dot) Katz" <jkatz(at)postgresql(dot)org>
Cc: David Rowley <dgrowleyml(at)gmail(dot)com>, John Naylor <john(dot)naylor(at)enterprisedb(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Robert Haas <robertmhaas(at)gmail(dot)com>, Yura Sokolov <y(dot)sokolov(at)postgrespro(dot)ru>, Tomas Vondra <tomas(dot)vondra(at)enterprisedb(dot)com>, Heikki Linnakangas <hlinnaka(at)iki(dot)fi>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Michael Paquier <michael(at)paquier(dot)xyz>
Subject: Re: PG15 beta1 sort performance regression due to Generation context change
Date: 2022-07-13 15:32:12
Message-ID: 20220713153212.zyae4ngtxycxy7tj@awork3.anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

On 2022-07-13 09:23:00 -0400, Jonathan S. Katz wrote:
> On 7/13/22 12:13 AM, David Rowley wrote:
> > On Tue, 12 Jul 2022 at 17:15, David Rowley <dgrowleyml(at)gmail(dot)com> wrote:
> > > 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?
> >
> > Let me handle this slightly differently. I've moved the open item for
> > this into the "won't fix" section. If nobody shouts at me for that
> > then I'll let that end the debate. Otherwise, we can consider the
> > argument when it arrives.
>
> The RMT discussed this issue at its meeting today (and a few weeks back --
> apologies for not writing sooner). While we agree with your analysis that 1/
> this issue does appear to be a corner case and 2/ the benefits outweigh the
> risks, we still don't know how prevalent it may be in the wild and the
> general impact to user experience.
>
> The RMT suggests that you make one more pass at attempting to solve it.

I think without a more concrete analysis from the RMT that's not really
actionable. What risks are we willing to accept to resolve this? This is
mostly a question of tradeoffs.

Several "senior" postgres hackers looked at this and didn't find any solution
that makes sense to apply to 15. I don't think having David butt his head
further against this code is likely to achieve much besides a headache. Note
that David already has a patch to address this for 16.

> If there does not appear to be a clear path forward, we should at least
> document how a user can detect and resolve the issue.

To me that doesn't really make sense. We have lots of places were performance
changes once you cross some threshold, and lots of those are related to
work_mem.

We don't, e.g., provide tooling to detect when performance in aggregation
regresses due to crossing work_mem and could be fixed by a tiny increase in
work_mem.

Greetings,

Andres Freund

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Pavel Borisov 2022-07-13 15:48:23 Re: XID formatting and SLRU refactorings (was: Add 64-bit XIDs into PostgreSQL 15)
Previous Message Tom Lane 2022-07-13 15:11:34 Re: Bug: Reading from single byte character column type may cause out of bounds memory reads.