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

David Rowley <dgrowleyml@gmail.com>

From: David Rowley <dgrowleyml@gmail.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: PostgreSQL Developers <pgsql-hackers@lists.postgresql.org>
Date: 2025-10-04T03:55:56Z
Lists: pgsql-hackers

Attachments

On Fri, 3 Oct 2025 at 10:02, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
> David Rowley <dgrowleyml@gmail.com> writes:
> > An alternative way would be to propagate those during build_setop_child_paths()
>
> That answer works for me.  I was expecting you to just document the
> need for the extra check in is_dummy_rel ;-) ... but this way is
> perhaps better.

So, I pushed the UNION portion earlier, but on hacking more on the
EXCEPT/INTERSECT patch, I noticed that I don't have the target lists
correct when marking the top-level set op as dummy. I had thought it
was ok to use the target list of the first child. I did that to make
EXPLAIN VERBOSE work as it chokes on the varno==0 top-level setop
targetlist as generated by generate_append_tlist(). However, using the
target list of the first child isn't right as createplan will choke on
not finding PathKeys to sort.

It looks like the normal UNION case side steps this issue for T_SetOp
by applying set_dummy_tlist_references() in setrefs.c. That doesn't
happen for Result since we may have something to evaluate there.

I'm just considering the best fix and can think of two options:

1) Move away from using varno==0 in generate_append_tlist(). Use varno==1, or;
2) Add handling in setrefs.c for T_Result to adjust varno==0 Vars to
use varno==1 vars.

The attached v4-0001 does #2, but wondering if #1 should be explored first.

David

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