Re: Parallel copy
vignesh C <vignesh21@gmail.com>
From: vignesh C <vignesh21@gmail.com>
To: Amit Kapila <amit.kapila16@gmail.com>
Cc: Ashutosh Sharma <ashu.coek88@gmail.com>,
Andres Freund <andres@anarazel.de>, Robert Haas <robertmhaas@gmail.com>, Ants Aasma <ants@cybertec.at>, Tomas Vondra <tomas.vondra@2ndquadrant.com>,
Alastair Turner <minion@decodable.me>, Thomas Munro <thomas.munro@gmail.com>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2020-06-17T04:10:09Z
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
Attachments
- 0005-Tests-for-parallel-copy.patch (text/x-patch) patch 0005
- 0004-Documentation-for-parallel-copy.patch (text/x-patch) patch 0004
- 0001-Copy-code-readjustment-to-support-parallel-copy.patch (text/x-patch) patch 0001
- 0002-Framework-for-leader-worker-in-parallel-copy.patch (text/x-patch) patch 0002
- 0003-Allow-copy-from-command-to-process-data-from-file-ST.patch (text/x-patch) patch 0003
- 0006-Parallel-Copy-For-Binary-Format-Files.patch (text/x-patch) patch 0006
Hi, I have included tests for parallel copy feature & few bugs that were identified during testing have been fixed. Attached patches for the same. Thoughts? Regards, Vignesh EnterpriseDB: http://www.enterprisedb.com On Tue, Jun 16, 2020 at 3:21 PM Amit Kapila <amit.kapila16@gmail.com> wrote: > > On Mon, Jun 15, 2020 at 7:41 PM Ashutosh Sharma <ashu.coek88@gmail.com> wrote: > > > > Thanks Amit for the clarifications. Regarding partitioned table, one of the question was - if we are loading data into a partitioned table using COPY command, then the input file would contain tuples for different tables (partitions) unlike the normal table case where all the tuples in the input file would belong to the same table. So, in such a case, how are we going to accumulate tuples into the DSM? I mean will the leader process check which tuple needs to be routed to which partition and accordingly accumulate them into the DSM. For e.g. let's say in the input data file we have 10 tuples where the 1st tuple belongs to partition1, 2nd belongs to partition2 and likewise. So, in such cases, will the leader process accumulate all the tuples belonging to partition1 into one DSM and tuples belonging to partition2 into some other DSM and assign them to the worker process or we have taken some other approach to handle this scenario? > > > > No, all the tuples (for all partitions) will be accumulated in a > single DSM and the workers/leader will route the tuple to an > appropriate partition. > > > Further, I haven't got much time to look into the links that you have shared in your previous response. Will have a look into those and will also slowly start looking into the patches as and when I get some time. Thank you. > > > > Yeah, it will be good if you go through all the emails once because > most of the decisions (and design) in the patch is supposed to be > based on the discussion in this thread. > > Note - Please don't top post, try to give inline replies. > > -- > With Regards, > Amit Kapila. > EnterpriseDB: http://www.enterprisedb.com