On Sat, Jun 4, 2016 at 1:53 AM, Robert Haas <
robertmhaas@gmail.com> wrote:
>
> 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;
>
That seems doable, as for such rels we can only have Vars and PlaceHolderVars in targetlist. Basically, whenever we are adding PlaceHolderVars to a relation, just remember that information and use it later. The patch doing the same is attached with this mail. Now still, this won't cover the case of ChildRels for an Append Relation as for that we adjust target list separately in set_append_rel_size. I think we need to deal with it separately.
