> On Thu, May 8, 2014 at 4:43 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> > I thought that the executor side of his patch wasn't in bad shape.
> > The real problems were in the planner, and indeed largely in the "backend"
> > part of the planner where there's a lot of hard-wired logic for fixing
> > up low-level details of the constructed plan tree. It seems like in
> > principle it might be possible to make that logic cleanly extensible,
> > but it'll likely take a major rewrite. The patch tried to skate by
> > with just exposing a bunch of internal functions, which I don't think
> > is a maintainable approach, either for the core or for the extensions
> using it.
>
> Well, I consider that somewhat good news, because I think it would be rather
> nice if we could get by with solving one problem at a time, and if the executor
> part is close to being well-solved, excellent.
>
> My ignorance is probably showing here, but I guess I don't understand why
> it's so hard to deal with the planner side of things. My perhaps-naive
> impression is that a Seq Scan node, or even an Index Scan node, is not all
> that complicated. If we just want to inject some more things that behave
> a lot like those into various baserels, I guess I don't understand why that's
> especially hard.
>
> Now I do understand that part of what KaiGai wants to do here is inject
> custom scan paths as additional paths for *joinrels*. And I can see why
> that would be somewhat more complicated. But I also don't see why that's
> got to be part of the initial commit.
>
I'd also like to take this approach. Even though we eventually need to take
a graceful approach for join replacement by custom-path, it partially makes
sense to have minimum functionality set first.
Then, we can focus on how to design planner integration for joinning.
Thanks,
--
NEC OSS Promotion Center / PG-Strom Project
KaiGai Kohei <kaigai@ak.jp.nec.com>