> On Thu, May 8, 2014 at 4:43 PM, Tom Lane <t...@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 <kai...@ak.jp.nec.com> -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
