On Thu, May 12, 2016 at 2:07 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: >> 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 ;-)
Hmm. Dilip's example in https://www.postgresql.org/message-id/CAFiTN-vzg5BkK6kAh3OMhvgRu-uJvkjz47ybtopMAfGJp=z...@mail.gmail.com seems to show that it's possible to end up with a targetlist containing non-Vars even for a baserel. In that example, pull_up_subqueries() injects t2 into the parent query with a target list containing two items, one of which is a PlaceHolderVar referencing the subplan for t3. Unfortunately, that makes it a bit hard to avoid wasting cycles here. Amit's patch in https://www.postgresql.org/message-id/CAA4eK1L-Uo=s4=0jvvva51pj06u5wddvsqg673yuxj_ja+x...@mail.gmail.com is a bit brute force: it just checks the target list for every relation for parallel-restricted constructs. In most cases, no subqueries having been pulled up, it will find none, but it'll still have to walk the whole target list to figure that out. If we had some way of knowing that nothing was pulled up into the current rel, we could avoid that. This seems to apply equally to baserels and appendrels; both will commonly have a target list containing only Vars, but both can end up with non-Vars in the target list after subqueries are pulled up. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
