From: | Kouhei Kaigai <kaigai(at)ak(dot)jp(dot)nec(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Andres Freund <andres(at)2ndquadrant(dot)com> |
Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, Simon Riggs <simon(at)2ndquadrant(dot)com>, PgHacker <pgsql-hackers(at)postgresql(dot)org>, Kohei KaiGai <kaigai(at)kaigai(dot)gr(dot)jp>, Stephen Frost <sfrost(at)snowman(dot)net>, Shigeru Hanada <shigeru(dot)hanada(at)gmail(dot)com>, Jim Mlodgenski <jimmy76(at)gmail(dot)com>, "Peter Eisentraut" <peter_e(at)gmx(dot)net> |
Subject: | Re: Custom Scan APIs (Re: Custom Plan node) |
Date: | 2014-04-16 04:11:11 |
Message-ID: | 9A28C8860F777E439AA12E8AEA7694F8F98B5E@BPXM15GP.gisp.nec.co.jp |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> Andres Freund <andres(at)2ndquadrant(dot)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".
>
Yep, today is the expected feature freeze date towards v9.4.
It is little bit late to include v9.4 features, unfortunately.
> 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.
>
Hmm. If we have something like expression_tree_walker/mutator for plan nodes,
we can pass a walker/mutator function's pointer instead of exposing static
functions that takes recursive jobs.
If custom-plan provider (that has sub-plans) got a callback with walker/
mutator pointer, all it has to do for sub-plans are calling this new
plan-tree walking support routine with supplied walker/mutator.
It seems to me more simple design than what I did.
Thanks,
--
NEC OSS Promotion Center / PG-Strom Project
KaiGai Kohei <kaigai(at)ak(dot)jp(dot)nec(dot)com>
From | Date | Subject | |
---|---|---|---|
Next Message | Hannu Krosing | 2014-04-16 04:12:45 | Re: Question about optimising (Postgres_)FDW |
Previous Message | Tom Lane | 2014-04-16 03:45:55 | Re: Create function prototype as part of PG_FUNCTION_INFO_V1 |