Re: get rid of RM_HEAP2_ID

From: John Naylor <johncnaylorls(at)gmail(dot)com>
To: Michael Paquier <michael(at)paquier(dot)xyz>
Cc: Heikki Linnakangas <hlinnaka(at)iki(dot)fi>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: get rid of RM_HEAP2_ID
Date: 2025-10-15 05:01:44
Message-ID: CANWCAZaEpLK9jAaY=G6+hgE0h9mBpqRoAv2qiPAvAV=fUBa_Rw@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Oct 15, 2025 at 6:55 AM Michael Paquier <michael(at)paquier(dot)xyz> wrote:
>
> On Tue, Oct 14, 2025 at 03:20:16PM +0300, Heikki Linnakangas wrote:
> > I'm not sure I agree with the premise that we should try to get rid of
> > RM_HEAP2_ID. There's nothing wrong with that scheme as such. As an
> > alternative, we could easily teach e.g pg_waldump to treat RM_HEAP_ID and
> > RM_HEAP2_ID the same for statistics purposes.
>
> Yeah, I'd rather keep heap2 as well. As long as there is more room
> for the record IDs, we're still going to need it in the long run.

Okay, I'll drop that aspect.

> We could move out xl_xid, which should not be required for all
> records, shaving 4 bytes from the base XLogRecord. I'm afraid of the
> duplication this would create if we push this data to each RMGR, which
> would, I guess, require a new RMGR callback to retrieve this field on
> a per-record basis. But perhaps it would not be that bad.

I've wondered if it would be possible to make xl_tot_len a varint that
starts in the last byte of the header, with the next bytes being like
XLogRecordDataHeader[Short|Long], but likewise using a varint.

--
John Naylor
Amazon Web Services

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Maxim Orlov 2025-10-15 05:12:32 Re: Patch for migration of the pg_commit_ts directory
Previous Message Bertrand Drouvot 2025-10-15 04:51:38 Re: Question about InvalidatePossiblyObsoleteSlot()