2013/9/10 Robert Haas <robertmhaas@gmail.com>:
> On Mon, Sep 9, 2013 at 1:20 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> 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.
>
> Fair enough, I think. So the action item for KaiGai is to think of
> how the planner integration might work.
>
Do you think the idea I mentioned at the upthread is worth to investigate
for more detailed consideration? Or, does it seems to you short-sighted
thinking to fit this infrastructure with planner?
It categorizes plan node into three: join, scan and other stuff.
Cost based estimation is almost applied on join and scan, so abstracted
scan and join may make sense to inform core planner what does this
custom plan node try to do.
On the other hand, other stuff, like Agg, is a stuff that must be added
according to the provided query, even if its cost estimation was not small,
to perform as the provided query described.
So, I thought important one is integration of join and scan, but manipulation
of plan tree for other stuff is sufficient.
How about your opinion?
Thanks,
--
KaiGai Kohei <kaigai@kaigai.gr.jp>
