Re: Custom Scan APIs (Re: Custom Plan node) - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Custom Scan APIs (Re: Custom Plan node)
Date
Msg-id 28743.1397576041@sss.pgh.pa.us
Whole thread Raw
In response to Re: Custom Scan APIs (Re: Custom Plan node)  (Andres Freund <andres@2ndquadrant.com>)
Responses Re: Custom Scan APIs (Re: Custom Plan node)  (Kouhei Kaigai <kaigai@ak.jp.nec.com>)
List pgsql-hackers
Andres Freund <andres@2ndquadrant.com> writes:
> What I think this discussion shows that this patch isn't ready for
> 9.4. The first iteration of the patch came in 2013-11-06. Imo that's
> pretty damn late for a relatively complex patch. And obviously we don't
> have agreement on the course forward.
> I don't think we need to stop discussing, but I think it's pretty clear
> that this isn't 9.4 material. And that it's far from "Ready for Committer".

Yeah.  I'm still not exactly convinced that custom-scan will ever allow
independent development of new plan types (which, with all due respect to
Robert, is what it was being sold as last year in Ottawa).  But I'm not
opposed in principle to committing it, if we can find a way to have a
cleaner API for things like setrefs.c.  It seems like late-stage planner
processing in general is an issue for this patch (createplan.c and
subselect.c are also looking messy).  EXPLAIN isn't too great either.

I'm not sure exactly what to do about those cases, but I wonder
whether things would get better if we had the equivalent of
expression_tree_walker/mutator capability for plan nodes.  The state
of affairs in setrefs and subselect, at least, is a bit reminiscent
of the bad old days when we had lots of different bespoke code for 
traversing expression trees.
        regards, tom lane



pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: Custom Scan APIs (Re: Custom Plan node)
Next
From: Merlin Moncure
Date:
Subject: Re: Clock sweep not caching enough B-Tree leaf pages?