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
