Horton

Re: [HACKERS] Parallel Append implementation

Thomas Munro <thomas.munro@enterprisedb.com>

View thread View on postgr.es
From: Thomas Munro <thomas.munro@enterprisedb.com>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Adrien Nayrat <adrien.nayrat@anayrat.info>, Amit Khandekar <amitdkhan.pg@gmail.com>, amul sul <sulamul@gmail.com>, pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2018-07-29T21:49:54Z
Lists: pgsql-hackers 
On Thu, May 10, 2018 at 7:08 AM, Robert Haas <robertmhaas@gmail.com> wrote:
>  [parallel-append-doc-v2.patch]

+    plans just as they can in any other plan.  However, in a parallel plan,
+    it is also possible that the planner may choose to substitute a
+    <literal>Parallel Append</literal> node.

Maybe drop "it is also possible that "?  It seems a bit unnecessary
and sounds a bit odd followed by "may <verb>", but maybe it's just me.

+    Also, unlike a regular <literal>Append</literal> node, which can only have
+    partial children when used within a parallel plan, <literal>Parallel
+    Append</literal> node can have both partial and non-partial child plans.

Missing "a" before "<literal>Parallel".

+    Non-partial children will be scanned by only a single worker, since

Are we using "worker" in a more general sense that possibly includes
the leader?  Hmm, yes, other text on this page does that too.  Ho hum.

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

Commits

  1. Update parallel.sgml for Parallel Append

  2. Support Parallel Append plan nodes.

  3. Remove BufFile's isTemp flag.

  4. Improve comments for parallel executor estimation functions.

  5. Separate reinitialization of shared parallel-scan state from ExecReScan.

  6. Eat XIDs more efficiently in recovery TAP test.

  7. Avoid syntax error on platforms that have neither LOCALE_T nor ICU.

  8. Preparatory refactoring for parallel merge join support.