Re: [HACKERS] Gather Merge - Mailing list pgsql-hackers

From Robert Haas
Subject Re: [HACKERS] Gather Merge
Date
Msg-id CA+TgmoZqKVq3Xym+5Y4mscGrtr6yxTn9JGQRMGhSMrTEExor9Q@mail.gmail.com
Whole thread Raw
In response to Re: [HACKERS] Gather Merge  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Tue, Mar 14, 2017 at 9:56 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
>> Cool, thanks for the review.  I'm not quite confident that we've found
>> all of the bugs here yet, but I think we're moving in the right
>> direction.
>
> I guess the real question here is why isn't Gather Merge more like
> Append and MergeAppend?  That is, why did you complicate matters
> by making it projection capable?  That seems like a pretty random
> decision from here.

Well, then it would be inconsistent with plain old Gather.  I thought
about going that route - ripping whatever projection logic Gather has
out and teaching the system that it's not projection-capable - but I
don't see what that buys us.  It's pretty useful to be able to project
on top of Gather-type nodes, because they will often be at the top of
the plan, just before returning the results to the user.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: [HACKERS] [COMMITTERS] pgsql: Fix cardinality estimates for parallel joins.
Next
From: Tom Lane
Date:
Subject: Re: [HACKERS] Upgrading postmaster's log messages about bind/listen errors