From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Rushabh Lathia <rushabh(dot)lathia(at)gmail(dot)com>, Andreas Joseph Krogh <andreas(at)visena(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>, Kuntal Ghosh <kuntalghosh(dot)2007(at)gmail(dot)com> |
Subject: | Re: Gather Merge |
Date: | 2017-03-14 16:36:10 |
Message-ID: | CA+TgmoZqKVq3Xym+5Y4mscGrtr6yxTn9JGQRMGhSMrTEExor9Q@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, Mar 14, 2017 at 9:56 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Robert Haas <robertmhaas(at)gmail(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2017-03-14 16:50:09 | Re: Upgrading postmaster's log messages about bind/listen errors |
Previous Message | Robert Haas | 2017-03-14 16:29:53 | Re: [COMMITTERS] pgsql: Fix cardinality estimates for parallel joins. |