| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Richard Guo <guofenglinux(at)gmail(dot)com> |
| Cc: | David Rowley <dgrowleyml(at)gmail(dot)com>, 邱宇航 <iamqyh(at)gmail(dot)com>, Bruce Momjian <bruce(at)momjian(dot)us>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Inconsistent Behavior of GROUP BY ROLLUP in v17 vs master |
| Date: | 2025-10-17 21:14:02 |
| Message-ID: | 1834667.1760735642@sss.pgh.pa.us |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
I wrote:
> The proposed patch tries to close the hole by checking whether
> the condition is degenerate, but that feels subtly wrong to me:
> what we ought to check is whether there is any empty grouping set.
> As proposed, I think we miss optimization opportunities for
> degenerate HAVING because we will not try the trick of copying
> it to WHERE.
Concretely, I think we could do the attached. This has the same
test query as in v1, but the generated plan is better because it
realizes it can copy the constant-false HAVING clause into WHERE,
resulting in a dummy scan of the table.
I'm not sure if planner.c is the best place to put
has_empty_grouping_set(). I couldn't find any existing code doing the
same thing, but maybe someday we'd want the functionality elsewhere.
regards, tom lane
| Attachment | Content-Type | Size |
|---|---|---|
| v2-0001-Fix-pushdown-of-degenerate-HAVING-clauses.patch | text/x-diff | 8.1 KB |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | David E. Wheeler | 2025-10-17 21:41:27 | Re: abi-compliance-check failure due to recent changes to pg_{clear,restore}_{attribute,relation}_stats() |
| Previous Message | Tomas Vondra | 2025-10-17 20:51:06 | Re: Fix overflow of nbatch |