Robert Haas <robertmh...@gmail.com> writes:
> On Wed, Mar 16, 2016 at 2:47 PM, Tom Lane <t...@sss.pgh.pa.us> wrote:
>> Robert Haas <robertmh...@gmail.com> writes:
>>> On Mon, Mar 14, 2016 at 9:21 PM, Kouhei Kaigai <kai...@ak.jp.nec.com> wrote:
>>>> So, even though we don't need to define multiple hook declarations,
>>>> I think the hook invocation is needed just after create_xxxx_paths()
>>>> for each. It will need to inform extension the context of hook
>>>> invocation, the argument list will take UpperRelationKind.
>>> That actually seems like a pretty good point. Otherwise you can't
>>> push anything from the upper rels down unless you are prepared to
>>> handle all of it.
>> I'm not exactly convinced of the use-case for that. What external
>> thing is likely to handle window functions but not aggregation,
>> for example?
> I'm not going to say that you're entirely wrong, but I think that
> attitude is a bit short-sighted.
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.
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.
Comments?
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
