Re: Proposal : Parallel Merge Join
Dilip Kumar <dilipbalaut@gmail.com>
From: Dilip Kumar <dilipbalaut@gmail.com>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Amit Kapila <amit.kapila16@gmail.com>,
pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2017-03-03T16:17:46Z
Lists: pgsql-hackers
On Fri, Mar 3, 2017 at 3:57 PM, Robert Haas <robertmhaas@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-qNvD7ZFaZbJWm3c0ysWyw@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 wrong. 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 outer? -- Regards, Dilip Kumar EnterpriseDB: http://www.enterprisedb.com
Commits
-
Consider parallel merge joins.
- 3bc7dafa9beb 10.0 landed
-
Preparatory refactoring for parallel merge join support.
- a71f10189dc1 10.0 landed
-
Fix parallel hash join path search.
- 655393a022bd 10.0 landed