Re: WIP: Upper planner pathification
От | Kouhei Kaigai |
---|---|
Тема | Re: WIP: Upper planner pathification |
Дата | |
Msg-id | 9A28C8860F777E439AA12E8AEA7694F8011CE78A@BPXM15GP.gisp.nec.co.jp обсуждение исходный текст |
Ответ на | Re: WIP: Upper planner pathification (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: WIP: Upper planner pathification
|
Список | pgsql-hackers |
> Robert Haas <robertmhaas@gmail.com> writes: > > On Mon, Mar 14, 2016 at 9:21 PM, Kouhei Kaigai <kaigai@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? > WindowPath usually takes a SortPath. Even though extension don't want to handle window function itself, it may want to add alternative sort logic than built-in. Unless it does not calculate expected cost, nobody knows whether WindowPath + SortPath is really cheaper than WindowPath + CustomPath("GpuSort"). The supplied query may require to run group-by prior to window function, but extension may not be interested in group-by on the other hands, thus, extension needs to get control around the location where built-in logic also adds paths to fetch the cheapest path of the underlying paths. Thanks, -- NEC Business Creation Division / PG-Strom Project KaiGai Kohei <kaigai@ak.jp.nec.com>
В списке pgsql-hackers по дате отправления: