From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | David Rowley <dgrowleyml(at)gmail(dot)com> |
Cc: | PostgreSQL Developers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Teaching planner to short-circuit empty UNION/EXCEPT/INTERSECT inputs |
Date: | 2025-10-02 03:21:48 |
Message-ID: | 976130.1759375308@sss.pgh.pa.us |
Views: | Whole Thread | Raw Message | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
David Rowley <dgrowleyml(at)gmail(dot)com> writes:
> In [1] there was a report that set operations didn't correctly detect
> when inputs were provably empty sets. While this is not the bug that
> the report claimed it to be, as it's just a missing optimisation, I
> did decide to look at it to check if there was much performance to
> gain from doing this.
I'm kind of resistant to the amount of code this patch adds in
comparison to the likely benefit. Sure, a badly written query can
profit, but is it worth debugging and maintaining a couple hundred
lines of code for that?
The first few hunks of changes seem fine by this light, but I think
you're expending too much effort on the EXCEPT-with-dummy-inputs
cases. 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.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | jian he | 2025-10-02 03:30:23 | Re: misleading error message in ProcessUtilitySlow T_CreateStatsStmt |
Previous Message | Nitin Motiani | 2025-10-02 03:16:48 | Re: pgstattuple "unexpected zero page" for gist and hash indexes |