Hi Kaigai-san, Sorry to leave the thread for a while.
2014-02-23 22:24 GMT+09:00 Kohei KaiGai <kai...@kaigai.gr.jp>: > (1) Interface to add alternative paths in addition to built-in join paths > > This patch adds "add_join_path_hook" on add_paths_to_joinrel to allow > extensions to provide alternative scan path in addition to the built-in > join paths. Custom-scan path being added is assumed to perform to scan > on a (virtual) relation that is a result set of joining relations. > My concern is its arguments to be pushed. This hook is declared as follows: > > /* Hook for plugins to add custom join path, in addition to default ones */ > typedef void (*add_join_path_hook_type)(PlannerInfo *root, > RelOptInfo *joinrel, > RelOptInfo *outerrel, > RelOptInfo *innerrel, > JoinType jointype, > SpecialJoinInfo *sjinfo, > List *restrictlist, > List *mergeclause_list, > SemiAntiJoinFactors *semifactors, > Relids param_source_rels, > Relids extra_lateral_rels); > extern PGDLLIMPORT add_join_path_hook_type add_join_path_hook; > > Likely, its arguments upper than restrictlist should be informed to > extensions, > because these are also arguments of add_paths_to_joinrel(). > However, I'm not 100% certain how about other arguments should be informed. > Probably, it makes sense to inform param_source_rels and extra_lateral_rels > to check whether the path is sensible for parameterized paths. > On the other hand, I doubt whether mergeclause_list is usuful to deliver. > (It may make sense if someone tries to implement their own merge-join > implementation??) > > I'd like to seem idea to improve the current interface specification. I've read the code path to add custom join again, and felt that providing semifactors seems not necessary for the first cut, because it is used in only initial_cost_nestloop (final_cost_nestloop receives semifactors but it is not used there), and external module would not become so smart before 9.5 development cycle. It seems enough complex to postpone determinig whether it's essential for add_join_path_hook. Do you have any concrete use case for the parameter? mergeclause_list and param_source_rels seem little easier to use, but anyway it should be documented how to use those parameters. IMHO, minimal interface seems better than fully-fledged but half-baked one, especially in the first-cut. -- Shigeru HANADA -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
