Re: Foreign join pushdown vs EvalPlanQual

On 2015/11/09 13:40, Kouhei Kaigai wrote:
>> 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've never denied that alternative local sub-plan is one of the best
> approach for postgres_fdw, however, I've also never heard why you can
> say the best approach for postgres_fdw is definitely also best for
> others.
> If we would justify less flexible interface specification because of
> comfort for a particular extension, it should not be an extension,
> but a built-in feature.
> My standpoint has been consistent through the discussion; we can never
> predicate which feature shall be implemented on FDW interface, therefore,
> we also cannot predicate which implementation is best for EPQ rechecks
> also. Only FDW driver knows which is the "best" for them, not us.

What the RecheckForeignScan routine does for the foreign-join case would 
be the following for tuples stored in estate->es_epqTuple[]:

1. Apply relevant restriction clauses, including fdw_recheck_quals, to 
the tuples for the baserels involved in a foreign-join, and see if the 
tuples still pass the clauses.

2. If so, form a join tuple, while applying relevant join clauses to the 
tuples, and set the join tuple in the given slot.  Else set empty.

I think these would be more efficiently processed internally in core 
than externally in FDWs.  That's why I don't see much value in adding 
the routine.  I have to admit that that means no flexibility, though.

However, the routine as-is doesn't seem good enough, either.  For 
example, since the routine is called after each of the tuples was 
re-fetched from the remote end or re-computed from the whole-row var and 
stored in the corresponding estate->es_epqTuple[], the routine wouldn't 
allow for what Robert proposed in [2].  To do such a thing, I think we 
would probably need to change the existing EPQ machinery more 
drastically and rethink the right place for calling the routine.

Best regards,
Etsuro Fujita

[2] 
http://www.postgresql.org/message-id/CA+TgmoZdPU_fcSpOzXxpD1xvyq3cZCAwD7-x3aVWbKgSFoHvRA@mail.gmail.com