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 по дате отправления: