2013/9/7 Tom Lane <tgl@sss.pgh.pa.us>:
> 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.
>
The reason why this patch stick on executor-side is we concluded
not to patch the planner code from the beginning in Ottawa because
of its complexity.
I'd also like to agree that planner support for custom plan is helpful
to construct better execution plan, however, it also make sense even
if this feature begins a functionality that offers a way to arrange a plan
tree being already constructed.
Anyway, let me investigate what's kind of APIs to be added for planner
stage also.
> 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.
>
Thanks,
--
KaiGai Kohei <kaigai@kaigai.gr.jp>
