Re: Foreign join pushdown vs EvalPlanQual

Hello,

At Wed, 7 Oct 2015 12:30:27 +0900, Etsuro Fujita <fujita(dot)etsuro(at)lab(dot)ntt(dot)co(dot)jp> wrote in <561491D3(dot)3070901(at)lab(dot)ntt(dot)co(dot)jp>
> On 2015/10/07 6:19, Robert Haas wrote:
> > On Fri, Oct 2, 2015 at 4:26 AM, Kyotaro HORIGUCHI
> > <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp> wrote:
> >> During join search, a joinrel should be comptible between local
> >> joins and remote joins, of course target list also should be
> >> so. So it is quite difficult to add wholerow resjunk for joinrels
> >> before whole join tree is completed even if we allow row marks
> >> that are not bound to base RTEs.
>
> > Suppose ROW_MARK_COPY is in use, and suppose the query is: SELECT
> > ft1.a, ft1.b, ft2.a, ft2.b FROM ft1, ft2 WHERE ft1.x = ft2.x;
> >
> > When the foreign join is executed, there's going to be a slot that
> > needs to be populated with ft1.a, ft1.b, ft2.a, ft2.b, and a whole row
> > reference. Now, let's suppose the slot descriptor has 5 columns: those
> > 4, plus a whole-row reference for ROW_MARK_COPY.
>
> 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.

> > 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.

cheers,

--
Kyotaro Horiguchi
NTT Open Source Software Center