Horton

Re: [HACKERS] Parallel Append implementation

Robert Haas <robertmhaas@gmail.com>

View thread View on postgr.es
From: Robert Haas <robertmhaas@gmail.com>
To: Thomas Munro <thomas.munro@enterprisedb.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-05-08T13:15:05Z
Lists: pgsql-hackers

Attachments

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.

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

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.