Horton

Re: Teaching planner to short-circuit empty UNION/EXCEPT/INTERSECT inputs

Tom Lane <tgl@sss.pgh.pa.us>

View thread View on postgr.es
From: Tom Lane <tgl@sss.pgh.pa.us>
To: David Rowley <dgrowleyml@gmail.com>
Cc: PostgreSQL Developers <pgsql-hackers@lists.postgresql.org>
Date: 2025-10-02T03:21:48Z
Lists: pgsql-hackers 
David Rowley <dgrowleyml@gmail.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

Commits

  1. Fix UNION planner estimate_num_groups with varno==0

  2. Fix possible usage of incorrect UPPERREL_SETOP RelOptInfo

  3. Teach planner to short-circuit EXCEPT/INTERSECT with dummy inputs

  4. Fix incorrect targetlist in dummy UNIONs

  5. Teach UNION planner to remove dummy inputs