Re: [HACKERS] Proposal : Parallel Merge Join - Mailing list pgsql-hackers

From Dilip Kumar
Subject Re: [HACKERS] Proposal : Parallel Merge Join
Date
Msg-id CAFiTN-u2kzm6wUpr2A9F1Q3Ya9wN8xSReG9OY1OKoRqi1+jtww@mail.gmail.com
Whole thread Raw
In response to Re: [HACKERS] Proposal : Parallel Merge Join  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: [HACKERS] Proposal : Parallel Merge Join
List 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



pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: [HACKERS] PATCH: recursive json_populate_record()
Next
From: Michael Paquier
Date:
Subject: Re: [HACKERS] exposing wait events for non-backends (was: Trackingwait event for latches)