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

On 2015/11/12 2:53, Robert Haas wrote:
> On Sun, Nov 8, 2015 at 11:13 PM, Etsuro Fujita
> <fujita.etsuro@lab.ntt.co.jp> wrote:
>> To test this change, I think we should update the postgres_fdw patch so as
>> to add the RecheckForeignScan.
>>
>> Having said that, as I said previously, I don't see much value in adding the
>> callback routine, to be honest.  I know KaiGai-san considers that that would
>> be useful for custom joins, but I don't think that that would be useful even
>> for foreign joins, because I think that in case of foreign joins, the
>> practical implementation of that routine in FDWs would be to create a
>> secondary plan and execute that plan by performing ExecProcNode, as my patch
>> does [1].  Maybe I'm missing something, though.

> I really don't see why you're fighting on this point.  Making this a
> generic feature will require only a few extra lines of code for FDW
> authors.  If this were going to cause some great inconvenience for FDW
> authors, then I'd agree it isn't worth it.  But I see zero evidence
> that this is actually the case.

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.

> From my point of view I'm now
> thinking this solution has two parts:
>
> (1) Let foreign scans have inner and outer subplans.  For this
> purpose, we only need one, but it's no more work to enable both, so we
> may as well.  If we had some reason, we could add a list of subplans
> of arbitrary length, but there doesn't seem to be an urgent need for
> that.
>
> (2) Add a recheck callback.
>
> If the foreign data wrapper wants to adopt the solution you're
> proposing, the recheck callback can call
> ExecProcNode(outerPlanState(node)).  I don't think this should end up
> being more than a few lines of code, although of course we should
> verify that.  So no problem: postgres_fdw and any other FDWs where the
> remote side is a database can easily delegate to a subplan, and
> anybody who wants to do something else still can.
>
> What is not to like about that?
>