Re: Adding CommandID to heap xlog records

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.

Kind regards,

Matthias van de Meent.