On Wed, 28 Sept 2022 at 19:40, Bruce Momjian <br...@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 <t...@sss.pgh.pa.us> wrote: > > > > > > Matthias van de Meent <boekewurm+postg...@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. Kind regards, Matthias van de Meent.