Re: [sqlsmith] Failed assertion in parallel worker (ExecInitSubPlan)
| От | Tom Lane |
|---|---|
| Тема | Re: [sqlsmith] Failed assertion in parallel worker (ExecInitSubPlan) |
| Дата | |
| Msg-id | 2859.1463076449@sss.pgh.pa.us обсуждение |
| Ответ на | Re: [sqlsmith] Failed assertion in parallel worker (ExecInitSubPlan) (Robert Haas <robertmhaas@gmail.com>) |
| Ответы |
Re: [sqlsmith] Failed assertion in parallel worker (ExecInitSubPlan)
Re: [sqlsmith] Failed assertion in parallel worker (ExecInitSubPlan) Re: [sqlsmith] Failed assertion in parallel worker (ExecInitSubPlan) |
| Список | pgsql-hackers |
Robert Haas <robertmhaas@gmail.com> writes:
>> Target list for a relation, you mean? See relation.h:
>>
>> * reltarget - Default Path output tlist for this rel; normally contains
>> * Var and PlaceHolderVar nodes for the values we need to
>> * output from this relation.
>> * List is in no particular order, but all rels of an
>> * appendrel set must use corresponding orders.
>> * NOTE: in an appendrel child relation, may contain
>> * arbitrary expressions pulled up from a subquery!
> Err, wow. That makes my head hurt. Can you explain why this case
> only arises for appendrel children, and not for plain rels?
Well, plain rels only output Vars ;-)
But consider an appendrel representing
(SELECT x+1 FROM t1 UNION ALL SELECT y+2 FROM t2) ss(a)
The RTE for ss will have a reltarget list containing just "a".
Once we pull up the subqueries, the reltarget lists for the two child
appendrel members will need to contain "x+1" and "y+2" in order to be
equivalent to the parent's reltarget list. See set_append_rel_size(),
which does that transformation.
This doesn't happen with ordinary subquery flattening because there
isn't a RelOptInfo corresponding to an ordinary subquery that's been
pulled up into the parent query.
regards, tom lane
В списке pgsql-hackers по дате отправления: