| From: | Jeff Davis <pgsql(at)j-davis(dot)com> |
|---|---|
| To: | Luc Vlaming <luc(at)swarm64(dot)com>, Bharath Rupireddy <bharath(dot)rupireddyforpostgres(at)gmail(dot)com>, Justin Pryzby <pryzby(at)telsasoft(dot)com> |
| Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Andres Freund <andres(at)anarazel(dot)de>, Paul Guo <guopa(at)vmware(dot)com> |
| Subject: | Re: New Table Access Methods for Multi and Single Inserts |
| Date: | 2021-01-05 21:28:59 |
| Message-ID: | f9a3e6d7e60a890e2feaac93055e27f61fb2b351.camel@j-davis.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | 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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2021-01-05 21:34:52 | Re: Libpq support to connect to standby server as priority |
| Previous Message | Alastair Turner | 2021-01-05 21:28:04 | Re: Proposed patch for key management |