public inbox for [email protected]  

help / color / mirror / Atom feed

From: Mark Dilger <[email protected]>
To: Alexander Korotkov <[email protected]>
Cc: PostgreSQL Hackers <[email protected]>
Subject: Re: Table AM Interface Enhancements
Date: Fri, 24 Nov 2023 07:18:36 -0800
Message-ID: <[email protected]> (raw)
In-Reply-To: <CAPpHfdurb9ycV8udYqM=o0sPS66PJ4RCBM1g-bBpvzUfogY0EA@mail.gmail.com>
References: <CAPpHfdurb9ycV8udYqM=o0sPS66PJ4RCBM1g-bBpvzUfogY0EA@mail.gmail.com>



> On Nov 23, 2023, at 4:42 AM, Alexander Korotkov <[email protected]> wrote:


> 0006-Generalize-table-AM-API-for-INSERT-.-ON-CONFLICT-v1.patch
> 
> Provides a new table AM API method to encapsulate the whole INSERT ...
> ON CONFLICT ... algorithm rather than just implementation of
> speculative tokens.

I *think* I understand that you are taking the part of INSERT..ON CONFLICT that lives outside the table AM and pulling it inside so that table AM authors are free to come up with whatever implementation is more suited for them.  The most straightforward way of doing so results in an EState parameter in the interface definition.  That seems not so good, as the EState is a fairly complicated structure, and future changes in the executor might want to rearrange what EState tracks, which would change which values tuple_insert_with_arbiter() can depend on.  Should the patch at least document which parts of the EState are expected to be in which states, and which parts should be viewed as undefined?  If the implementors of table AMs rely on any/all aspects of EState, doesn't that prevent future changes to how that structure is used?

> 0008-Let-table-AM-insertion-methods-control-index-inse-v1.patch
> 
> Allows table AM to skip index insertions in the executor and handle
> those insertions itself.

The new parameter could use more documentation.

> 0009-Custom-reloptions-for-table-AM-v1.patch
> 
> Enables table AMs to define and override reloptions for tables and indexes.

This could use some regression tests to exercise the custom reloptions.

—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

view thread (3+ messages)  latest in thread

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: [email protected]
  Cc: [email protected], [email protected], [email protected]
  Subject: Re: Table AM Interface Enhancements
  In-Reply-To: <[email protected]>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox