Re: get rid of RM_HEAP2_ID
| От | John Naylor | 
|---|---|
| Тема | Re: get rid of RM_HEAP2_ID | 
| Дата | |
| Msg-id | CANWCAZaEpLK9jAaY=G6+hgE0h9mBpqRoAv2qiPAvAV=fUBa_Rw@mail.gmail.com обсуждение исходный текст  | 
		
| Ответ на | Re: get rid of RM_HEAP2_ID (Michael Paquier <michael@paquier.xyz>) | 
| Ответы | 
                	
            		Re: get rid of RM_HEAP2_ID
            		
            		 | 
		
| Список | pgsql-hackers | 
On Wed, Oct 15, 2025 at 6:55 AM Michael Paquier <michael@paquier.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
В списке pgsql-hackers по дате отправления: