Re: Foreign join pushdown vs EvalPlanQual - Mailing list pgsql-hackers

From Robert Haas
Subject Re: Foreign join pushdown vs EvalPlanQual
Date
Msg-id CA+TgmoYmiswyMDyaRW1RoarTw8aP4wgJ0-bm4Lq-hJfY1WbYag@mail.gmail.com
Whole thread Raw
In response to Re: Foreign join pushdown vs EvalPlanQual  (Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp>)
Responses Re: Foreign join pushdown vs EvalPlanQual  (Etsuro Fujita <fujita.etsuro@lab.ntt.co.jp>)
List pgsql-hackers
On Fri, Oct 2, 2015 at 4:26 AM, Kyotaro HORIGUCHI
<horiguchi.kyotaro@lab.ntt.co.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.  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.

Is this a dumb idea, or could it work?

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: Obsolete comment in tidpath.c
Next
From: Robert Haas
Date:
Subject: Re: Connection string parameter 'replication' in documentation