Re: New Table Access Methods for Multi and Single Inserts

From: Luc Vlaming <luc(at)swarm64(dot)com>
To: Jeff Davis <pgsql(at)j-davis(dot)com>, Bharath Rupireddy <bharath(dot)rupireddyforpostgres(at)gmail(dot)com>
Cc: Justin Pryzby <pryzby(at)telsasoft(dot)com>, 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-18 07:58:08
Message-ID: 2281baee-081c-7360-cb51-4f16e1e91d8c@swarm64.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 17-01-2021 00:04, Jeff Davis wrote:
>
>> If we agree on removing heap_multi_insert_v2 API and embed that logic
>> inside heap_insert_v2, then we can do this - pass the required
>> information and the functions ExecInsertIndexTuples and
>> ExecARInsertTriggers as callbacks so that, whether or not
>> heap_insert_v2 choses single or multi inserts, it can callback these
>> functions with the required information passed after the flush. We
>> can
>> add the callback and required information into TableInsertState. But,
>> I'm not quite sure, we would make ExecInsertIndexTuples and
>> ExecARInsertTriggers.
>
> How should the API interact with INSERT INTO ... SELECT? Right now it
> doesn't appear to be integrated at all, but that seems like a fairly
> important path for bulk inserts.
>
> Regards,
> Jeff Davis
>
>

Hi,

You mean how it could because of that the table modification API uses
the table_tuple_insert_speculative ? Just wondering if you think if it
generally cannot work or would like to see that path / more paths
integrated in to the patch.

Kind regards,
Luc

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Craig Ringer 2021-01-18 07:59:40 [PATCH] ProcessInterrupts_hook
Previous Message Craig Ringer 2021-01-18 07:56:47 [PATCH] More docs on what to do and not do in extension code