From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Kyotaro HORIGUCHI <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp> |
Cc: | Etsuro Fujita <fujita(dot)etsuro(at)lab(dot)ntt(dot)co(dot)jp>, Kohei KaiGai <kaigai(at)ak(dot)jp(dot)nec(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>, Shigeru Hanada <shigeru(dot)hanada(at)gmail(dot)com> |
Subject: | Re: Foreign join pushdown vs EvalPlanQual |
Date: | 2015-10-07 04:24:57 |
Message-ID: | CA+TgmoZRqXdtPh-RPbX-fRSdq+_c8U6dXcTovu+zgY0hrnR6TQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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.
>> > 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.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
From | Date | Subject | |
---|---|---|---|
Next Message | Kyotaro HORIGUCHI | 2015-10-07 06:06:32 | Re: Foreign join pushdown vs EvalPlanQual |
Previous Message | Robert Haas | 2015-10-07 04:18:44 | Re: Foreign join pushdown vs EvalPlanQual |