Re: Ordering behavior for aggregates

From: "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>
To: Ronan Dunklau <ronan(dot)dunklau(at)aiven(dot)io>
Cc: pgsql-hackers(at)lists(dot)postgresql(dot)org, Magnus Hagander <magnus(at)hagander(dot)net>, Vik Fearing <vik(at)postgresfriends(dot)org>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Subject: Re: Ordering behavior for aggregates
Date: 2022-12-13 17:15:12
Message-ID: CAKFQuwZ0yx81sXNWzW6GHEX+nFzjgX_w8jLExxF9u+uxZfJp1w@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Dec 13, 2022 at 9:45 AM Ronan Dunklau <ronan(dot)dunklau(at)aiven(dot)io>
wrote:

> Le mardi 13 décembre 2022, 16:13:34 CET Tom Lane a écrit :
> > Accordingly, I find nothing at all attractive in this proposal.
> > I think the main thing it'd accomplish is to drive users back to
> > the bad old days of ordering-by-subquery, if they have a requirement
> > we failed to account for.
>
> I think the ability to mark certain aggregates as being able to completely
> ignore the ordering because they produce exactly the same results is still
> a
> useful optimization.
>
>
I seriously doubt that users are adding unnecessary ORDER BY clauses to
their aggregates. The more compelling use case would be existing ORMs that
produce such problematic SQL - are there any though?

I'm more keen on the idea of having the system understand when an ORDER BY
is missing - that seems like what users are more likely to actually do.
But it doesn't seem all that useful given the lack of aggregates that would
actually use it meaningfully.

David J.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Geoghegan 2022-12-13 17:16:19 Re: New strategies for freezing, advancing relfrozenxid early
Previous Message Tom Lane 2022-12-13 17:05:14 Re: Ordering behavior for aggregates