On Sun, Feb 26, 2017 at 12:01 PM, Robert Haas <robertmh...@gmail.com> wrote: > On Fri, Feb 24, 2017 at 3:54 PM, Amit Kapila <amit.kapil...@gmail.com> wrote: >> 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. > > TBH, I think Dilip had the right idea here. cheapest_total_inner > isn't anything magical; it's just that there's no reason to use > anything but the cheapest path for a relation when forming a join path > unless that first path lacks some property that you need, like having > the right sortkeys or being parallel-safe. Since there are lots of > join paths that just want to do things in the cheapest way possible, > we identify the cheapest path and hang on to it; when that's not what > we need, we go find the path or paths that have the properties we > want. I'm not sure why this case should be an exception. You could > argue that if the cheapest parallel-safe path is already more > expensive then the parallel join may not pay off, but that's hard to > say; it depends on what happens higher up in the plan tree. >
Okay, but in that case don't you think it is better to consider the parallel safety of cheapest_total_inner only when we don't find any cheap parallel_safe innerpath by reducing the sort keys? -- 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
