Re: [HACKERS] Parallel Append implementation

On Wed, May 9, 2018 at 1:15 AM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> On Tue, May 8, 2018 at 12:10 AM, Thomas Munro
> <thomas(dot)munro(at)enterprisedb(dot)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