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