Re: Custom Plan node

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> 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?

No, for exactly the reason you mention: such a change wouldn't have been
accounted for in the planner's other choices, and thus this isn't anything
more than a kluge.

In these specific examples you'd have to ask whether it wouldn't make more
sense to be modifying or hooking the executor's code for the existing plan
node types, anyway. The main reason I can see for not attacking it like
that would be if you wanted the planner to do something different ---
which the above approach forecloses.

Let me be clear that I'm not against the concept of custom plan nodes.
But it was obvious from the beginning that making the executor deal with
them would be much easier than making the planner deal with them. I don't
think we should commit a bunch of executor-side infrastructure in the
absence of any (ahem) plan for doing something realistic on the planner
side. Either that infrastructure will go unused, or we'll be facing a
continual stream of demands for doubtless-half-baked planner changes
so that people can do something with it.

I'd be willing to put in the infrastructure as soon as it's clear that we
have a way forward, but not if it's never going to be more than a kluge.

regards, tom lane