Re: Adding CommandID to heap xlog records - Mailing list pgsql-hackers

From Ian Lawrence Barwick
Subject Re: Adding CommandID to heap xlog records
Date
Msg-id CAB8KJ=jhqoz6p8wSJO5PKm=3bmkODY4kdBcVBp+7N5twX3KYCQ@mail.gmail.com
Whole thread Raw
In response to Re: Adding CommandID to heap xlog records  (Matthias van de Meent <boekewurm+postgres@gmail.com>)
Responses Re: Adding CommandID to heap xlog records
List pgsql-hackers
2022年9月30日(金) 1:04 Matthias van de Meent <boekewurm+postgres@gmail.com>:
>
> On Wed, 28 Sept 2022 at 19:40, Bruce Momjian <bruce@momjian.us> wrote:
> >
> > On Thu, Sep 22, 2022 at 11:12:32PM +0200, Matthias van de Meent wrote:
> > > On Thu, 8 Sept 2022 at 23:24, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> > > >
> > > > Matthias van de Meent <boekewurm+postgres@gmail.com> writes:
> > > > > Please find attached a patch that adds the CommandId of the inserting
> > > > > transaction to heap (batch)insert, update and delete records. It is
> > > > > based on the changes we made in the fork we maintain for Neon.
> > > >
> > > > This seems like a very significant cost increment with returns
> > > > to only a minuscule number of users.  We certainly cannot consider
> > > > it unless you provide some evidence that that impression is wrong.
> > >
> > > Attached a proposed set of patches to reduce overhead of the inital patch.
> >
> > This might be obvious to some, but the patch got a lot larger.  :-(
>
> Sorry for that, but updating the field from which the redo manager
> should pull its information does indeed touch a lot of files because
> most users of xl_info are only interested in the 4 bits reserved for
> the redo-manager. Most of 0001 is therefore updates to point code to
> the new field in XLogRecord, and renaming the variables and arguments
> from info to rminfo.
>
> [tangent] With that refactoring, I also clean up a lot of code that
> was using a wrong macro/constant for rmgr flags; `info &
> ~XLR_INFO_MASK` may have the same value as `info &
> XLR_RMGR_INFO_MASK`, but that's only guaranteed by the documentation;
> and would require the same significant rework if new bits were
> assigned to non-XLR_INFO_MASK and non-XLR_RMGR_INFO_MASK. [/tangent]
>
> 0002 grew a bit as well, but not to a degree that I think is worrying
> or otherwise impossible to review.

Hi

This entry was marked as "Needs review" in the CommitFest app but cfbot
reports the patch no longer applies.

We've marked it as "Waiting on Author". As CommitFest 2022-11 is
currently underway, this would be an excellent time update the patch.

Once you think the patchset is ready for review again, you (or any
interested party) can  move the patch entry forward by visiting

    https://commitfest.postgresql.org/40/3882/

and changing the status to "Needs review".


Thanks

Ian Barwick



pgsql-hackers by date:

Previous
From: Ian Lawrence Barwick
Date:
Subject: Re: XID formatting and SLRU refactorings (was: Add 64-bit XIDs into PostgreSQL 15)
Next
From: Ian Lawrence Barwick
Date:
Subject: Re: Commit fest 2022-11