Re: WIP: Upper planner pathification
От | Kouhei Kaigai |
---|---|
Тема | Re: WIP: Upper planner pathification |
Дата | |
Msg-id | 9A28C8860F777E439AA12E8AEA7694F8011CAF7D@BPXM15GP.gisp.nec.co.jp обсуждение исходный текст |
Ответ на | Re: WIP: Upper planner pathification (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: WIP: Upper planner pathification
(Robert Haas <robertmhaas@gmail.com>)
|
Список | pgsql-hackers |
> -----Original Message----- > From: Tom Lane [mailto:tgl@sss.pgh.pa.us] > Sent: Tuesday, March 15, 2016 2:04 AM > To: Petr Jelinek > Cc: Kaigai Kouhei(海外 浩平); David Rowley; Robert Haas; > pgsql-hackers@postgresql.org > Subject: Re: [HACKERS] WIP: Upper planner pathification > > Petr Jelinek <petr@2ndquadrant.com> writes: > > On 14/03/16 02:43, Kouhei Kaigai wrote: > >> Even though I couldn't check the new planner implementation entirely, > >> it seems to be the points below are good candidate to inject CustomPath > >> (and potentially ForeignScan). > >> > >> - create_grouping_paths > >> - create_window_paths > >> - create_distinct_paths > >> - create_ordered_paths > >> - just below of the create_modifytable_path > >> (may be valuable for foreign-update pushdown) > > > To me that seems too low inside the planning tree, perhaps adding it > > just to the subquery_planner before SS_identify_outer_params would be > > better, that's the place where you see the path for the whole (sub)query > > so you can search and modify what you need from there. > > I don't like either of those too much. The main thing I've noticed over > the past few days is that you can't readily generate custom upper-level > Paths unless you know what PathTarget grouping_planner is expecting each > level to produce. So what I was toying with doing is (1) having > grouping_planner put all those targets into the PlannerInfo, perhaps > in an array indexed by UpperRelationKind; and (2) adding a hook call > immediately after those targets are computed, say right before > the create_grouping_paths() call (approximately planner.c:1738 > in HEAD). It should be sufficient to have one hook there since > you can inject Paths into any of the upper relations at that point; > moreover, that's late enough that you shouldn't have to recompute > anything you figured out during scan/join planning. > Regarding to the (2), I doubt whether the location is reasonable, because pathlist of each upper_rels[] are still empty, aren't it? It will make extension not-easy to construct its own CustomPath that takes underlying built-in pathnodes. For example, an extension implements its own sort logic but not interested in group-by/window function, it shall want to add its CustomPath to UPPERREL_ORDERED, however, it does not know which is the input_rel and no built-in paths are not added yet at the point of create_upper_paths_hook(). On the other hands, here is another problem if we put a hook after all the upper paths done. In this case, built-in create_xxxx_paths() functions cannot pay attention for CustomPath to be added later when these functions pick up the cheapest path. 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. In addition, extension cannot reference some local variables from the root structure, like:- rollup_lists- rollup_groupclauses- wflists- activeWindows- have_postponed_srfs As we are doing at set_join_pathlist_hook, it is good idea to define UpperPathExtraData structure to pack misc information. So, how about to re-define the hook as follows? typedef void (*create_upper_paths_hook_type) (UpperRelationKind upper_kind, PlannerInfo*root, RelOptInfo *scan_join_rel, UpperPathExtraData *extra); Thanks, -- NEC Business Creation Division / PG-Strom Project KaiGai Kohei <kaigai@ak.jp.nec.com>
В списке pgsql-hackers по дате отправления:
Предыдущее
От: Kouhei KaigaiДата:
Сообщение: Re: Reworks of CustomScan serialization/deserialization