* Simon Riggs (simon@2ndQuadrant.com) wrote:
> >From here, it looks exactly like pushing a join into an FDW. If we had
> that, we wouldn't need Custom Scan at all.
>
> I may be mistaken and there is a critical difference. Local sub-plans
> doesn't sound like a big difference.
Erm. I'm not sure that you're really thinking through what you're
suggesting.
Allow me to re-state your suggestion here:
An FDW is loaded which provides hook for join push-down (whatever those
end up being).
A query is run which joins *local* table A to *local* table B. Standard
heaps, standard indexes, all local to this PG instance.
The FDW which supports join push-down is then passed this join for
planning, with local sub-plans for the local tables.
> Have we considered having an Optimizer and Executor plugin that does
> this without touching core at all?
Uh, isn't that what we're talking about? The issue is that there's a
bunch of internal functions that such a plugin would need to either have
access to or re-implement, but we'd rather not expose those internal
functions to the whole world because they're, uh, internal helper
routines, essentially, which could disappear in another release.
The point is that there isn't a good API for this today and what's being
proposed isn't a good API, it's just bolted-on to the existing system by
exposing what are rightfully internal routines.
Thanks,
Stephen
