Re: Adding CommandID to heap xlog records

On Mon, 16 Jan 2023 at 19:56, vignesh C <vignesh21(at)gmail(dot)com> wrote:
>
> On Thu, 3 Nov 2022 at 15:06, Ian Lawrence Barwick <barwick(at)gmail(dot)com> wrote:
> >
> > 2022年9月30日(金) 1:04 Matthias van de Meent <boekewurm+postgres(at)gmail(dot)com>:
> > >
> > > On Wed, 28 Sept 2022 at 19:40, Bruce Momjian <bruce(at)momjian(dot)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(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> > > > > >
> > > > > > Matthias van de Meent <boekewurm+postgres(at)gmail(dot)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".
>
> I was not sure if you will be planning to post an updated version of
> patch as the patch has been awaiting your attention from last
> commitfest, please post an updated version for it soon or update the
> commitfest entry accordingly.

There has been no updates on this thread for some time, so this has
been switched as Returned with Feedback. Feel free to open it in the
next commitfest if you plan to continue on this.

Regards,
Vignesh