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

Поиск
Список
Период
Сортировка
От David Rowley
Тема Re: Teaching planner to short-circuit empty UNION/EXCEPT/INTERSECT inputs
Дата
Msg-id CAApHDvo5v+dpos_4_CR49_2y8rpAbExBEmrYo0QGHagW8BQOzA@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Teaching planner to short-circuit empty UNION/EXCEPT/INTERSECT inputs  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
On Sun, 5 Oct 2025 at 04:43, Tom Lane <tgl@sss.pgh.pa.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



В списке pgsql-hackers по дате отправления: