* Simon Riggs (si...@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
Description: Digital signature