> > ----------------<cut here>----------------
> > @@ -85,6 +86,18 @@ ForeignRecheck(ForeignScanState *node, TupleTableSlot
> *slot)
> >
> > ResetExprContext(econtext);
> >
> > + /*
> > + * FDW driver has to recheck visibility of EPQ tuple towards
> > + * the scan qualifiers once it gets pushed down.
> > + * In addition, if this node represents a join sub-tree, not
> > + * a scan, FDW driver is also responsible to reconstruct
> > + * a joined tuple according to the primitive EPQ tuples.
> > + */
> > + if (fdwroutine->RecheckForeignScan)
> > + {
> > + if (!fdwroutine->RecheckForeignScan(node, slot))
> > + return false;
> > + }
> > return ExecQual(node->fdw_recheck_quals, econtext, false);
> > }
> > ----------------<cut here>----------------
> >
> > If callback is invoked first, FDW driver can reconstruct a joined tuple
> > with its comfortable way, then remaining checks can be done by ExecQual
> > and fds_recheck_quals on the caller side.
> > If callback would be located on the tail, FDW driver has no choice.
>
> 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'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.
Thanks,
--
NEC Business Creation Division / PG-Strom Project
KaiGai Kohei <kaigai@ak.jp.nec.com>
