|From:||Robert Haas <robertmhaas(at)gmail(dot)com>|
|To:||Dilip Kumar <dilipbalaut(at)gmail(dot)com>|
|Subject:||Re: Proposal : Parallel Merge Join|
|Views:||Raw Message | Whole Thread | Download mbox|
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
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.
The Enterprise PostgreSQL Company
|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?|