Re: Foreign join pushdown vs EvalPlanQual

On Sun, Nov 8, 2015 at 11:13 PM, Etsuro Fujita
<fujita(dot)etsuro(at)lab(dot)ntt(dot)co(dot)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. 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?

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