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