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.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company