Re: New Table Access Methods for Multi and Single Inserts
Luc Vlaming <luc@swarm64.com>
From: Luc Vlaming <luc@swarm64.com>
To: Jeff Davis <pgsql@j-davis.com>,
Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>,
Justin Pryzby <pryzby@telsasoft.com>
Cc: PostgreSQL-development <pgsql-hackers@postgresql.org>,
Andres Freund <andres@anarazel.de>, Paul Guo <guopa@vmware.com>
Date: 2021-01-06T07:00:55Z
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 →
-
libpq: Fix some issues in TAP tests for service files
- 2c7bd2ba507e 18.0 cited
-
Multiple revisions to the GROUP BY reordering tests
- 874d817baa16 17.0 cited
-
Explore alternative orderings of group-by pathkeys during optimization.
- 0452b461bc40 17.0 cited
On 05-01-2021 22:28, Jeff Davis wrote: > On Mon, 2021-01-04 at 08:59 +0100, Luc Vlaming wrote: >> Reason I'm asking is that I quite liked the heap_insert_begin >> parameter >> is_multi, which could even be turned into a "expected_rowcount" of >> the >> amount of rows expected to be commited in the transaction (e.g. >> single, >> several, thousands/stream). > > Do you mean "written by the statement" instead of "committed in the > transaction"? It doesn't look like the TableInsertState state will > survive across statement boundaries. > > Though that is an important question to consider. If the premise is > that a given custom AM may be much more efficient at bulk inserts than > retail inserts (which is reasonable), then it makes sense to handle the > case of a transaction with many single-tuple inserts. But keeping > insert state across statement boundaries also raises a few potential > problems. > > Regards, > Jeff Davis > > I did actually mean until the end of the transaction. I know this is currently not possible with the current design but I think it would be cool to start going that way (even if slightly). Creating some more freedom on how a tableam optimizes inserts, when one syncs to disk, etc would be good imo. It would allow one to create e.g. a tableam that would not have as a high overhead when doing single statement inserts. Kind regards, Luc