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

From: David Rowley <dgrowleyml(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
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-05 00:56:44
Message-ID: CAApHDvo5v+dpos_4_CR49_2y8rpAbExBEmrYo0QGHagW8BQOzA@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sun, 5 Oct 2025 at 04:43, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> In particular it's not clear to me why varno==1 is better? As best
> I can recall without diving into code, the fundamental mismatch is
> that varno zero doesn't correspond to any RTE. It would be better
> if the Vars matched the subquery RTEs that are at the base of the
> set-operation nest, so that there were a useful referent as to where
> a Var came from. Arbitrarily setting varno=1 sounds like the worst
> case: we could neither identify a Var with a source subquery
> accurately, nor realize that its varno is phony.

I've not tried it yet, but the idea with varno==1 is that is that it
does index the first UNION child's RTE. For the case at hand, all the
children are dummies. I thought doing this was ok because Appends and
MergeAppends show the target entries for the first child, and cases
like the following do show Vars from RTEs that don't get scanned in
the plan:

# explain verbose select * from t where 1=2 order by 1;

Sort (cost=0.01..0.02 rows=0 width=0)
Output: a, b
Sort Key: t.a
-> Result (cost=0.00..0.00 rows=0 width=0)
Output: a, b
Replaces: Scan on t
One-Time Filter: false

Another alternative that I'm thinking about which might be better is
to double-down on the varno==0 and invent a special varno and define
SETOP_VAR. I'd feel better about doing that as I didn't feel good
about coding the magic number for the if(var->varno == 0) check in
set_plan_refs() to make the T_Result work in EXPLAIN VERBOSE.

David

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Thomas Munro 2025-10-05 01:05:26 Re: We broke the defense against accessing other sessions' temp tables
Previous Message Tom Lane 2025-10-04 21:36:53 Re: We broke the defense against accessing other sessions' temp tables