> > I also think that there are really two separate problems here: getting > > the executor to call a custom scan node when it shows up in the plan > > tree; and figuring out how to get it into the plan tree in the first > > place. I'm not sure we've properly separated those problems, and I'm > > not sure into which category the issues that sunk KaiGai's 9.4 patch > > fell. > > 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. > (I'm now trying to catch up the discussion last night...)
I initially intended to allow extensions to add their custom-path based on their arbitrary decision, because the core backend cannot have expectation towards the behavior of custom-plan. However, of course, the custom-path that replaces built-in paths shall have compatible behavior in spite of different implementation. So, I'm inclined to the direction that custom-plan provider will inform the core backend what they can do, and planner will give extensions more practical information to construct custom path node. Let me investigate how to handle join replacement by custom-path in the planner stage. 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
