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. -- Petr Jelinek http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
