Re: Parallel copy
Greg Nancarrow <gregn4422@gmail.com>
From: Greg Nancarrow <gregn4422@gmail.com>
To: Amit Kapila <amit.kapila16@gmail.com>
Cc: vignesh C <vignesh21@gmail.com>, Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>, Rafia Sabih <rafia.pghackers@gmail.com>,
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-10-09T08:06:33Z
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 Fri, Oct 9, 2020 at 5:40 PM Amit Kapila <amit.kapila16@gmail.com> wrote: > > > Looking a bit deeper into this, I'm wondering if in fact your > > EstimateStringSize() and EstimateNodeSize() functions should be using > > BUFFERALIGN() for EACH stored string/node (rather than just calling > > shm_toc_estimate_chunk() once at the end, after the length of packed > > strings and nodes has been estimated), to ensure alignment of start of > > each string/node. Other Postgres code appears to be aligning each > > stored chunk using shm_toc_estimate_chunk(). See the definition of > > that macro and its current usages. > > > > I am not sure if this required for the purpose of correctness. AFAIU, > we do store/estimate multiple parameters in same way at other places, > see EstimateParamListSpace and SerializeParamList. Do you have > something else in mind? > The point I was trying to make is that potentially more efficient code can be used if the individual strings/nodes are aligned, rather than packed (as they are now), but as you point out, there are already cases (e.g. SerializeParamList) where within the separately-aligned chunks the data is not aligned, so maybe not a big deal. Oh well, without alignment, that means use of memcpy() cannot really be avoided here for serializing/de-serializing ints etc., let's hope the compiler optimizes it as best it can. Regards, Greg Nancarrow Fujitsu Australia