On Thu, Mar 17, 2016 at 2:31 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Well, I'm prepared to yield to the extent of repeating the hook call > before each phase with an UpperRelationKind parameter to tell which phase > we're about to do. The main concern here is to avoid redundant > computation, but the hook can check the "kind" parameter and fall out > quickly if it has nothing useful to do at the current phase. > > I do not, however, like the proposal to expose wflists and so forth. > Those are internal data structures in grouping_planner and I absolutely > refuse to promise that they're going to stay stable. (I had already > been thinking a couple of weeks ago about revising the activeWindows > data structure, now that it would be reasonably practical to cost out > different orders for doing the window functions in.) I think a hook > that has its own ideas about window function implementation methods > can gather its own information about the WFs without that much extra > cost, and it very probably wouldn't want exactly the same data that > create_window_paths uses today anyway. > > So what I would now propose is > > typedef void (*create_upper_paths_hook_type) (PlannerInfo *root, > UpperRelationKind stage, > RelOptInfo *input_rel); > > and have this invoked at each stage right before we call > create_grouping_paths, create_window_paths, etc.
Works for me. > Also, I don't particularly see a need for a corresponding API for FDWs. > If an FDW is going to do anything in this space, it presumably has to > build up ForeignPaths for all the steps anyway. So I'd be inclined > to leave GetForeignUpperPaths as-is. No idea if that is going to be a significant limitation or not. Doesn't seem like it should be, but what do I know? -- 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
