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

From Robert Haas
Subject Re: Foreign join pushdown vs EvalPlanQual
Date
Msg-id CA+TgmoYiS=GbPacYYE7o3Ft=L-8=CfGUFhjfHe3WPb2rUJy-kg@mail.gmail.com
Whole thread Raw
In response to Re: Foreign join pushdown vs EvalPlanQual  (Etsuro Fujita <fujita.etsuro@lab.ntt.co.jp>)
Responses Re: Foreign join pushdown vs EvalPlanQual  (Etsuro Fujita <fujita.etsuro@lab.ntt.co.jp>)
List pgsql-hackers
On Thu, Nov 12, 2015 at 12:54 AM, Etsuro Fujita
<fujita.etsuro@lab.ntt.co.jp> wrote:
> Really?  I think there would be not a little burden on an FDW author; when
> postgres_fdw delegates to the subplan to the remote server, for example, it
> would need to create a remote join query by looking at tuples possibly
> fetched and stored in estate->es_epqTuple[], send the query and receive the
> result during the callback routine.  Furthermore, what I'm most concerned
> about is that wouldn't be efficient.  So, my question about that approach is
> whether FDWs really do some thing like that during the callback routine,
> instead of performing a secondary join plan locally.  As I said before, I
> know that KaiGai-san considers that that approach would be useful for custom
> joins.  But I see zero evidence that there is a good use-case for an FDW.

It could do that.  But it could also just invoke a subplan as you are
proposing.  Or at least, I think we should set it up so that such a
thing is possible.  In which case I don't see the problem.

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



pgsql-hackers by date:

Previous
From: Nikolay Shaplov
Date:
Subject: Re: pageinspect patch, for showing tuple data
Next
From: "andres@anarazel.de"
Date:
Subject: Re: [PATCH] Refactoring of LWLock tranches