On Fri, Mar 3, 2017 at 3:57 PM, Robert Haas <robertmh...@gmail.com> wrote:
> I'm not happy with the way this patch can just happen to latch on to a
> path that's not parallel-safe rather than one that is and then just
> give up on a merge join in that case.  I already made this argument in
> https://www.postgresql.org/message-id/ca+tgmobdw2au1jq5l4ysa2zhqfma-qnvd7zfazbjwm3c0ys...@mail.gmail.com
> and my opinion hasn't changed.

I think last time I did not understand the depth of the problem
completely and only fixed from one aspect that in
generate_partial_mergejoin_paths if cheapest_total_inner or
cheapest_startup_inner is not parallel safe then consider the current
path if that are parallel safe and now I got it how it was completely

I have one question for fixing it in sort_inner_and_outer,  Currently,
we don't consider the parameterized paths for merge join except the
case when cheapest total paths itself is parameterized, So IIUC, for
creating partial path we will check if cheapest_total_inner path is
not parallel safe then we will find cheapest inner parallel safe path
using your new API get_cheapest_parallel_safe_total_inner, and we will
proceed with this paths if this is not directly parameterized by

Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com

Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to