Re: Proposal : Parallel Merge Join

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

In response to

Responses

Browse pgsql-hackers by date

  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?