Re: [PATCH] GROUP BY ALL

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: David Christensen <david(at)pgguru(dot)net>
Cc: Andrey Borodin <x4mmm(at)yandex-team(dot)ru>, Peter Eisentraut <peter(at)eisentraut(dot)org>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>, Jelte Fennema-Nio <postgres(at)jeltef(dot)nl>
Subject: Re: [PATCH] GROUP BY ALL
Date: 2025-09-26 16:23:35
Message-ID: 4085064.1758903815@sss.pgh.pa.us
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

David Christensen <david(at)pgguru(dot)net> writes:
> On Fri, Sep 26, 2025 at 11:05 AM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> contain_agg_clause will blow up on a SubLink, so I doubt this is
>> gonna be robust.

> Fair enough, see that Assert now; easy enough to make a new
> expression_tree_walker that only looks for Aggref and short-circuits
> SubLink (which I assume is the right behavior here, but might have to
> add some more tests/play around with subqueries in the GROUP BY ALL
> part).

No, I think the correct behavior would have to be to descend into
SubLinks to see if they contain any aggregates belonging to the
outer query level.

However (looks around) we do already have that code.
See contain_aggs_of_level. (contain_agg_clause is essentially
a simplified version that is okay to use in the planner because
it's already gotten rid of sublinks.)

What mainly concerns me at this point is whether we've identified
aggregate levels at the point in parsing where you want to run this.
I have a bit of a worry that that might interact with grouping.
Presumably the SQL committee thought about that, so it's probably
soluble, but ...

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2025-09-26 16:24:37 Re: [PATCH] GROUP BY ALL
Previous Message Fabrice Chapuis 2025-09-26 16:21:58 Re: Issue with logical replication slot during switchover