Re: Proposal : Parallel Merge Join
Dilip Kumar <dilipbalaut@gmail.com>
From: Dilip Kumar <dilipbalaut@gmail.com>
To: Robert Haas <robertmhaas@gmail.com>
Cc: pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2016-12-13T01:12:40Z
Lists: pgsql-hackers
On Tue, Dec 13, 2016 at 12:11 AM, Robert Haas <robertmhaas@gmail.com> wrote: > > Hmm, so it seems my initial guess that we didn't need to bother > generating such paths was wrong. Oops. > > This patch is hard to read because it is reorganizing a bunch of code > as well as adding new functionality. Perhaps you could separate it > into two patches, one with the refactoring and then the other with the > new functionality. Okay, I can do that. > Actually, though, I don't understand why you need > so much rearrangement.... Actually match_unsorted_outer is quite complex function and considering merge join path for many cases, And In my opinion those all paths should be considered for partial outer as well. So one option was to duplicate that part of code. But I chose to move all that code from match_unsorted_outer (which is related to generating various merge join path) to new function called generate_mergejoin_path. And, use it for normal outer path as well as for partial outer path. -- 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