On Fri, Feb 24, 2017 at 3:04 PM, Amit Kapila <amit.kapil...@gmail.com> wrote: > What advantage do you see for considering such a path when the cost of > innerpath is more than cheapest_total_inner? Remember the more paths > we try to consider, the more time we spend in the planner. By any > chance are you able to generate any query where it will give benefit > by considering costlier innerpath?
Changed > > 2. > +static void generate_parallel_mergejoin_paths(PlannerInfo *root, > + RelOptInfo *joinrel, > + RelOptInfo *innerrel, > + Path *outerpath, > + JoinType jointype, > + JoinPathExtraData *extra, > + Path *inner_cheapest_total, > + List *merge_pathkeys); > > It is better to name this function as > generate_partial_mergejoin_paths() as we are generating only partial > paths in this function and accordingly change the comment on top of > the function. I see that you might be naming it based on > consider_parallel_*, however, I think it is better to use partial in > the name as that is what we are doing inside that function. Also, I > think this function has removed/changed some handling related to > unique outer and full joins, so it is better to mention that in the > function comments, something like "unlike above function, this > function doesn't expect to handle join types JOIN_UNIQUE_OUTER or > JOIN_FULL" and add Assert for both of those types. Done > > 3. > A test case is still missing. Added -- Regards, Dilip Kumar EnterpriseDB: http://www.enterprisedb.com
parallel_mergejoin_v6.patch
Description: Binary data
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
