On Fri, Sep 6, 2013 at 7:03 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
>> I find this a somewhat depressing response. Didn't we discuss this
>> exact design at the developer meeting in Ottawa? I thought it sounded
>> reasonable to you then, or at least I don't remember you panning it.
>
> What I recall saying is that I didn't see how the planner side of it would
> work ... and I still don't see that. I'd be okay with committing
> executor-side fixes only if we had a vision of where we'd go on the
> planner side; but this patch doesn't offer any path forward there.
>
> This is not unlike the FDW stuff, where getting a reasonable set of
> planner APIs in place was by far the hardest part (and isn't really done
> even yet, since you still can't do remote joins or remote aggregation in
> any reasonable fashion). But you can do simple stuff reasonably simply,
> without reimplementing all of the planner along the way --- and I think
> we should look for some equivalent level of usefulness from this before
> we commit it.
I do think there are problems with this as written. The example
consumer of the hook seems to contain a complete list of plan nodes,
which is an oxymoron in the face of a facility to add custom plan
nodes.
But, I guess I'm not yet convinced that one-for-one substitution of
nodes is impossible even with something about this simple. If someone
can do a post-pass over the plan tree and replace a SeqScan node with
an AwesomeSeqScan node or a Sort node with a RadixSort node, would
that constitute a sufficient POC to justify this infrastructure?
Obviously, what you'd really want is to be able to inject those nodes
(with proper costing) at the time they'd otherwise be generated, since
it could affect whether or not a path involving a substituted node
survives in the first place, but I'm not sure it's reasonable to
expect the planner infrastructure for such changes in the same path as
the executor hooks.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company