On Thu, May 12, 2016 at 2:07 PM, Tom Lane <tgl@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=zWqA@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+x86Q@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
