On Sun, Feb 26, 2017 at 12:01 PM, Robert Haas <robertmhaas@gmail.com> wrote:
> On Fri, Feb 24, 2017 at 3:54 PM, Amit Kapila <amit.kapila16@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