Hi, On 2023-05-18 19:22:26 +0300, Heikki Linnakangas wrote: > On 18/05/2023 17:59, Matthias van de Meent wrote: > > Attached is a patch that reduces this overhead by up to 2 bytes by > > encoding how large the block data length field is into the block ID, > > and thus optionally reducing the block data's length field to 0 bytes. > > Examples: cross-page update records will now be 2 bytes shorter, > > because the record never registers any data for the new block of the > > update; pgbench transactions are now either 6 or 8 bytes smaller > > depending on whether the update crosses a page boundary (in xlog > > record size; after alignment it is 0 or 4/8 bytes, depending on > > MAXALIGN and whether the updates are cross-page updates). > > > > It changes the block IDs used to fit in 6 bits, using the upper 2 bits > > of the block_id field to store how much data is contained in the > > record (0, <=UINT8_MAX, or <=UINT16_MAX bytes). > > Perhaps we should introduce a few generic inline functions to do varint > encoding. That could be useful in many places, while this scheme is very > tailored for XLogRecordBlockHeader.
Yes - I proposed that and wrote an implementation of reasonably efficient varint encoding. Here's my prototype: https://postgr.es/m/20221004234952.anrguppx5owewb6n%40awork3.anarazel.de I think it's a bad tradeoff to write lots of custom varint encodings, just to eek out a bit more space savings. The increase in code complexity IMO makes it a bad tradeoff. Greetings, Andres Freund