Re: Foreign join pushdown vs EvalPlanQual

Hello,

At Wed, 7 Oct 2015 00:24:57 -0400, Robert Haas <robertmhaas(at)gmail(dot)com> wrote in <CA+TgmoZRqXdtPh-RPbX-fRSdq+_c8U6dXcTovu+zgY0hrnR6TQ(at)mail(dot)gmail(dot)com>
> On Wed, Oct 7, 2015 at 12:10 AM, Kyotaro HORIGUCHI
> <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp> wrote:
> >> IIUC, I think that if ROW_MARK_COPY is in use, the descriptor would
> >> have 6 columns: those 4, plus a whole-row var for ft1 and another
> >> whole-row bar for ft2. Maybe I'm missing something, though.
> >
> > You're right. The result tuple for the Robert's example has 6
> > attributes in the order of [ft1.a, ft1.b, (ft1.a, ft1.b), ft2.a...]
> >
> > But the point of the discussion is in another point. The problem
> > is when such joins are joined with another local table. For such
> > case, the whole-row reference for the intermediate foreign-join
> > would lose the targets in top-level tuple.
>
> Really? Would that mean that ROW_MARK_COPY is totally broken? I bet it's not.

The semantics of ROW_MARK_COPY is the tuple should hold whole-row
*value* as in resjunk column. I should misunderstood "whole row
*reference*" by confising planner and executor behaviors. I
understood the new story as adding to a tuple a reference to
itself. If it is wrong and the correct story is having additional
whole-row *value* in the whole joined tuple including resjunks
passed from the underlying tuples, it should work.

> >> > 4, plus a whole-row reference for ROW_MARK_COPY. If we know what
> >> > values we're going to store in columns 1..4, couldn't we just form
> >> > them into a tuple to populate column 5? We don't actually need to be
> >> > able to fetch such a tuple from the remote side because we can just
> >> > construct it. I think.
> >>
> >> I also was thinking whether we could replace one of the whole-row vars
> >> with a whole-row var that represents the scan slot of the
> >> ForeignScanState node.
> >
> > I suppose it requires additional resjunk to be added on joinrel
> > creation, which is what Kaigai-san said as overkill. But I'm
> > interedted in what it looks.
>
> I think it rather requires *replacing* two resjunk columns by one new
> one. The whole-row references for the individual foreign tables are
> only there to support EvalPlanQual; if we instead have a column to
> populate the foreign scan's slot directly, then we can use that column
> for that purpose directly and there's no remaining use for the
> whole-row vars on the baserels.

It is what I had in mind. Target lists for joinrels cannot be
built straight-forward way as it is.

regards,

--
Kyotaro Horiguchi
NTT Open Source Software Center