Re: [HACKERS] Parallel Append implementation - Mailing list pgsql-hackers

From Thomas Munro
Subject Re: [HACKERS] Parallel Append implementation
Date
Msg-id CAEepm=3=X1XgNhY6r0dHrKiCk4Es_x+RDettE2A9z1GEaj5p9g@mail.gmail.com
Whole thread Raw
In response to Re: [HACKERS] Parallel Append implementation  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: [HACKERS] Parallel Append implementation  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
On Wed, May 9, 2018 at 1:15 AM, Robert Haas <robertmhaas@gmail.com> wrote:
> On Tue, May 8, 2018 at 12:10 AM, Thomas Munro
> <thomas.munro@enterprisedb.com> wrote:
>> It's not a scan, it's not a join and it's not an aggregation so I
>> think it needs to be in a new <sect2> as the same level as those
>> others.  It's a different kind of thing.
>
> I'm a little skeptical about that idea because I'm not sure it's
> really in the same category as far as importance is concerned, but I
> don't have a better idea.  Here's a patch.  I'm worried this is too
> much technical jargon, but I don't know how to explain it any more
> simply.

+    scanning them more than once would preduce duplicate results.  Plans that

s/preduce/produce/

+    <literal>Append</literal> or <literal>MergeAppend</literal> plan node.
vs.
+    Append</literal> of regular <literal>Index Scan</literal> plans; each

I think we should standardise on <literal>Foo Bar</literal>,
<literal>FooBar</literal> or <emphasis>foo bar</emphasis> when
discussing executor nodes on this page.

-- 
Thomas Munro
http://www.enterprisedb.com


pgsql-hackers by date:

Previous
From: Peter Eisentraut
Date:
Subject: Re: perlcritic script
Next
From: "Tels"
Date:
Subject: Re: perlcritic script