Re: Custom Scan APIs (Re: Custom Plan node)

On Tue, Mar 4, 2014 at 7:39 PM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:

> On Mon, Mar 3, 2014 at 5:15 PM, Stephen Frost <sfrost(at)snowman(dot)net> wrote:
> >> As I mentioned
> >> up-thread, I'd really like to see FDW join push-down, FDW aggregate
> >> push-down, parallel query execution, and parallel remote-FDW execution
> >> and I don't see this CustomScan approach as the right answer to any of
> >> those.
> >
> > In accordance with the above, what I'd like to see with this patch is
> > removal of the postgres_fdw changes and any changes which were for that
> > support. In addition, I'd like to understand why 'ctidscan' makes any
> > sense to have as an example of what to use this for- if that's valuable,
> > why wouldn't we simply implement that in core? I do want an example in
> > contrib of how to properly use this capability, but I don't think that's
> > it.
>
> I suggested that example to KaiGai at last year's PGCon. It may
> indeed be something we want to have in core, but right now we don't.
>
> More generally, I think this discussion is focusing on the wrong set
> of issues. The threshold issue for this patch is whether there is a
> set of hook points that enable a workable custom-scan functionality,
> and whether KaiGai has correctly identified them. In other words, I
> think we should be worrying about whether KaiGai's found all of the
> places that need to be modified to support a custom scan, and whether
> the modifications he's made to each of those places are correct and
> adequate. Whether he's picked the best possible example does not
> strike me as a matter of principal concern, and it's far too late to
> tell him he's got to go pick a different one at this point anyway.
>
>
There are so many places in the planner and optimizer code, where we create
various types of paths and the number of such paths is again significant,
if not large. If we want the custom scan contrib module to work in all
those cases (which seems to be the intention here), then we have to expose
so many hooks. I don't think all of those hooks have been identified.
Second problem is, the functions which create those paths have signatures
difficult enough to be exposed as hooks. Take example of the join hook that
was exposed. These function signatures do get changed from time to time and
thus corresponding hooks need to be changed to. This is going to be a
maintenance burden.

So, unless we have some way of exposing these hooks such that the
definitions of the hooks are independent of the internal function
signatures, supporting custom scan looks difficult.

> --
> Robert Haas
> EnterpriseDB: http://www.enterprisedb.com
> The Enterprise PostgreSQL Company
>
>
> --
> Sent via pgsql-hackers mailing list (pgsql-hackers(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers
>

--
Best Wishes,
Ashutosh Bapat
EnterpriseDB Corporation
The Postgres Database Company