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. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers