From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Dilip Kumar <dilipbalaut(at)gmail(dot)com> |
Cc: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Proposal : Parallel Merge Join |
Date: | 2016-12-21 15:09:51 |
Message-ID: | CA+TgmoaYTieGpLy2TuB3RyyjbKEqrdYvXori1wWHY8DYD5yM1g@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, Dec 13, 2016 at 10:04 AM, Dilip Kumar <dilipbalaut(at)gmail(dot)com> wrote:
> On Tue, Dec 13, 2016 at 6:42 AM, Dilip Kumar <dilipbalaut(at)gmail(dot)com> wrote:
>>> 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.
>
> I have created two patches as per the suggestion.
>
> 1. mergejoin_refactoring_v2.patch --> Move functionality of
> considering various merge join path into new function.
> 2. parallel_mergejoin_v2.patch -> This adds the functionality of
> supporting partial mergejoin paths. This will apply on top of
> mergejoin_refactoring_v2.patch.
Committed the refactoring patch with some mild cosmetic adjustments.
As to the second patch:
+ if (jointype == JOIN_UNIQUE_INNER)
+ jointype = JOIN_INNER;
Isn't this dead code? save_jointype might that value, but jointype won't.
Apart from that and some cosmetic issues it looks basically OK to me
on a first read-through.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
From | Date | Subject | |
---|---|---|---|
Next Message | Anastasia Lubennikova | 2016-12-21 15:16:52 | Re: Parallel Index Scans |
Previous Message | Tom Lane | 2016-12-21 14:39:49 | Re: Why does plpython delay composite type resolution? |