On 8 May 2014 14:40, Stephen Frost <sfrost@snowman.net> wrote:
> 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.
Yes that is correct; thank you for confirming your understanding with me.
That also supports custom join of local to non-local table, or custom
join of two non-local tables.
If we can use interfaces that already exist with efficiency, why
invent a new one?
>> 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?
No. I meant writing this as an extension rather than a patch on core.
> 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.
I think the main point is that people don't want to ask for our
permission before they do what they want to do.
We either help people use Postgres, or they go elsewhere.
-- Simon Riggs http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training & Services