Re: Parallel copy

Amit Kapila <amit.kapila16@gmail.com>

From: Amit Kapila <amit.kapila16@gmail.com>

To: Tomas Vondra <tomas.vondra@2ndquadrant.com>

Cc: Ants Aasma <ants@cybertec.at>, Alastair Turner <minion@decodable.me>, Thomas Munro <thomas.munro@gmail.com>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>

Date: 2020-02-19T13:04:46Z

Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

Allow WaitLatch() to be used without a latch.
- 733fa9aa51c5 14.0 cited
Add %P to log_line_prefix for parallel group leader
- b8fdee7d0ca8 14.0 cited
Include replication origins in SQL functions for commit timestamp
- b1e48bbe64a4 14.0 cited
Avoid useless buffer allocations during binary COPY FROM.
- cd22d3cdb9bd 14.0 cited

On Wed, Feb 19, 2020 at 4:08 PM Tomas Vondra
<tomas.vondra@2ndquadrant.com> wrote:
>
> The one piece of information I'm missing here is at least a very rough
> quantification of the individual steps of CSV processing - for example
> if parsing takes only 10% of the time, it's pretty pointless to start by
> parallelising this part and we should focus on the rest. If it's 50% it
> might be a different story.
>

Right, this is important information to know.

> Has anyone done any measurements?
>

Not yet, but planning to work on it.

-- 
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com