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

From Robert Haas
Subject Re: [HACKERS] Parallel Append implementation
Date
Msg-id CA+TgmoaFcpFfvdjiui5=+daCN6hNJfSWKQyAQbWH88qZUxe_=Q@mail.gmail.com
Whole thread Raw
In response to Re: [HACKERS] Parallel Append implementation  (Thomas Munro <thomas.munro@enterprisedb.com>)
Responses Re: [HACKERS] Parallel Append implementation
List pgsql-hackers
On Tue, May 8, 2018 at 5:05 PM, Thomas Munro
<thomas.munro@enterprisedb.com> wrote:
> +    scanning them more than once would preduce duplicate results.  Plans that
>
> s/preduce/produce/

Fixed, thanks.

> +    <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.

Well, EXPLAIN prints MergeAppend but Index Scan, and I think we should
follow that precedent here.

As for <emphasis> vs. <literal>, I think the reason I ended up using
<emphasis> in the section on scans was because I thought that
<literal>Parallel Seq Scan</literal> might be confusing (what's a
"seq"?), so I tried to fudge my way around that by referring to it as
an abstract idea rather than the exact EXPLAIN output.  You then
copied that style in the join section, and, well, like you say, now we
have a sort of hodgepodge of styles.  Maybe that's a problem for
another patch, though.

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

Attachment

pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: [HACKERS] Clock with Adaptive Replacement
Next
From: Peter Geoghegan
Date:
Subject: Re: [HACKERS] Clock with Adaptive Replacement