Re: New Table Access Methods for Multi and Single Inserts - Mailing list pgsql-hackers

From Jeff Davis
Subject Re: New Table Access Methods for Multi and Single Inserts
Date
Msg-id f9a3e6d7e60a890e2feaac93055e27f61fb2b351.camel@j-davis.com
Whole thread Raw
In response to Re: New Table Access Methods for Multi and Single Inserts  (Luc Vlaming <luc@swarm64.com>)
Responses Re: New Table Access Methods for Multi and Single Inserts  (Luc Vlaming <luc@swarm64.com>)
List pgsql-hackers
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





pgsql-hackers by date:

Previous
From: Alastair Turner
Date:
Subject: Re: Proposed patch for key management
Next
From: Tom Lane
Date:
Subject: Re: Libpq support to connect to standby server as priority