> -----Original Message----- > From: Petr Jelinek [mailto:p...@2ndquadrant.com] > Sent: Monday, March 14, 2016 12:18 PM > To: Kaigai Kouhei(海外 浩平); Tom Lane; David Rowley > Cc: Robert Haas; pgsql-hackers@postgresql.org > Subject: Re: [HACKERS] WIP: Upper planner pathification > > On 14/03/16 02:43, Kouhei Kaigai wrote: > > > > CustomPath node is originally expected to generate various kind of plan > > node, not only scan/join, and its interface is designed to support them. > > For example, we can expect a CustomPath that generates "CustomSort". > > > > On the other hands, upper path consideration is more variable than the > > case of scan/join path consideration. Probably, we can have no centralized > > point to add custom-paths for sort, group-by, ... > > So, I think we have hooks for each (supported) upper path workload. > > > > In case of sorting for example, the best location of the hook is just > > above of the Assert() in the create_ordered_paths(). It allows to compare > > estimated cost between SortPath and CustomPath. > > However, it does not allow to inject CustomPath(for sort) into the path > > node that may involve sorting, like WindowPath or AggPath. > > Thus, another hook may be put on create_window_paths and > > create_grouping_paths in my thought. > > > > Some other good idea? > > > > 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. > Thanks for your idea. Yes, I also thought a similar point; where all the path consideration get completed. It indeed allows extensions to walk down the path tree and replace a part of them. However, when we want to inject CustomPath under the built-in paths, extension has to re-calculate cost of the built-in paths again. Perhaps, it affects to the decision of built-in path selection. So, I concluded that it is not realistic to re-implement equivalent upper planning stuff in the extension side, if we put the hook after all the planning works done.
If extension can add its CustomPath at create_grouping_paths(), the later steps, like create_window_paths, stands on the estimated cost of the CustomPath. Thus, extension don't need to know the detail of the entire upper planning. Thanks, -- NEC Business Creation Division / 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
