| From: | Mingli Zhang <zmlpostgres(at)gmail(dot)com> |
|---|---|
| To: | David Rowley <dgrowleyml(at)gmail(dot)com> |
| Cc: | PostgreSQL Developers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Subject: | Re: Teaching planner to short-circuit empty UNION/EXCEPT/INTERSECT inputs |
| Date: | 2025-10-02 13:55:36 |
| Message-ID: | CANG7CAKhk+z0c7tO2LWXG6VtHrV3-uqc0zN=F=bjd=22uzmSrA@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Hi,
David Rowley <dgrowleyml(at)gmail(dot)com>于2025年10月2日 周四20:09写道：
> On Thu, 2 Oct 2025 at 16:21, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> > I'm wondering if it could be shortened a great deal by
> > handling left-input-dummy and EXCEPT-ALL-with-right-input-dummy
> > but leaving the EXCEPT-with-right-input-dummy case unimproved.
>
> Good idea. Less code and still get to keep the one that did well in
> the benchmark. See attached.
>
> I ended up splitting the patch in two. 0001 for UNION only, then 0002
> for the INTERSECT and EXCEPT.
>
> David
It seems that the optimization for `UNION ALL` is already implemented in
the patch: it removes empty sub-paths and preserves the remaining ones.
Should we add a test case to formally validate this behavior like Union
cases?
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Alexander Korotkov | 2025-10-02 14:49:26 | Re: MergeAppend could consider sorting cheapest child path |
| Previous Message | Dmitry Koval | 2025-10-02 13:26:00 | Re: Add SPLIT PARTITION/MERGE PARTITIONS commands |