Re: Table AM Interface Enhancements

From: Alexander Korotkov <aekorotkov(at)gmail(dot)com>
To: Mark Dilger <mark(dot)dilger(at)enterprisedb(dot)com>
Cc: PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Table AM Interface Enhancements
Date: 2024-03-03 11:50:38
Message-ID: CAPpHfduNh1iTo1KGBLAWBBt6MZQ00YkSVvUPgFDp6vUKY5Qo8w@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, Nov 27, 2023 at 10:18 PM Mark Dilger
<mark(dot)dilger(at)enterprisedb(dot)com> wrote:
>
> > On Nov 25, 2023, at 9:47 AM, Alexander Korotkov <aekorotkov(at)gmail(dot)com> wrote:
> >
> >> 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?
> >
> > New tuple tuple_insert_with_arbiter() table AM API method needs EState
> > argument to call executor functions: ExecCheckIndexConstraints(),
> > ExecUpdateLockMode(), and ExecInsertIndexTuples(). I think we
> > probably need to invent some opaque way to call this executor function
> > without revealing EState to table AM. Do you think this could work?
>
> We're clearly not accessing all of the EState, just some specific fields, such as es_per_tuple_exprcontext. I think you could at least refactor to pass the minimum amount of state information through the table AM API.

Yes, the table AM doesn't need the full EState, just the ability to do
specific manipulation with tuples. I'll refactor the patch to make a
better isolation for this.

------
Regards,
Alexander Korotkov

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Alvaro Herrera 2024-03-03 13:58:39 Re: SLRU optimization - configurable buffer pool and partitioning the SLRU lock
Previous Message Alexander Korotkov 2024-03-03 11:48:07 Re: Table AM Interface Enhancements