On Fri, Feb 24, 2017 at 3:42 PM, Dilip Kumar <dilipbal...@gmail.com> wrote: > On Fri, Feb 24, 2017 at 3:04 PM, Amit Kapila <amit.kapil...@gmail.com> wrote: > > Thanks for the comments. > >> 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? > > If inner_cheapest_total path is not parallel safe then I am trying to > find the cheapest parallel safe path and generate partial merge join. >
Not sure, if we can just ignore the cheapest inner path because it is not parallel safe. It is also possible that you pick costly inner path just because it is parallel safe and then, later on, you have to discard it because the overall cost of partial merge join is much more. > I agree that it will consider one extra path while considering every > partial merge join path > Hmm, AFAICS, it will consider two extra paths per sort key (the loop around considering such paths is up to num_sortkeys) > (I think with this addition we will not get > parallel merge path for the any more TPCH query). I feel in general > we can get some better plan by this especially when gather is the > cheapest path for inner relation(which is not parallel safe) but at > the cost of considering some extra paths. I agree in some cases it could be better, but I think benefits are not completely clear, so probably we can leave it as of now and if later any one comes with a clear use case or can see the benefits of such path then we can include it. -- With Regards, Amit Kapila. EnterpriseDB: http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
