public inbox for [email protected]  
help / color / mirror / Atom feed
From: Mark Dilger <[email protected]>
To: Matthias van de Meent <[email protected]>
Cc: PostgreSQL Hackers <[email protected]>
Cc: Heikki Linnakangas <[email protected]>
Cc: Robert Haas <[email protected]>
Cc: Dilip Kumar <[email protected]>
Cc: Andres Freund <[email protected]>
Subject: Re: XLog size reductions: Reduced XLog record header size for PG17
Date: Wed, 5 Jun 2024 08:12:47 -0700
Message-ID: <[email protected]> (raw)
In-Reply-To: <CAEze2WgcW5SkPO_TGTqirRcCS_FN0xEZqUsXDE6pPz2TYzXQBA@mail.gmail.com>
References: <CAEze2WgcW5SkPO_TGTqirRcCS_FN0xEZqUsXDE6pPz2TYzXQBA@mail.gmail.com>



> On Jun 20, 2023, at 1:01 PM, Matthias van de Meent <[email protected]> wrote:
> 
> 0001 is copied essentially verbatim from [1] and reduces overhead in
> the registered block's length field where possible. It is included to
> improve code commonality between varcoded integer fields. See [1] for
> more details.

Hi Matthias!  I am interested in seeing this patch move forward.  We seem to be stuck.

The disagreement on the other thread seems to be about whether we can generalize and reuse variable integer encoding.  Could you comment on whether perhaps we just need a few versions of that?  Perhaps one version where the number of length bytes is encoded in the length itself (such as is used for varlena and by Andres' patch) and one where the number of length bytes is stored elsewhere?  You are clearly using the "elsewhere" form, but perhaps you could pull out the logic of that into src/common?  In struct XLogRecordBlockHeader.id <http://xlogrecordblockheader.id/;, you are reserving two bits for the size class.  (The code comments aren't clear about this, by the way.)  Perhaps if the generalized length encoding logic could take a couple arguments to represent where and how the size class bits are to be stored, and where the length itself is stored?  I doubt you need to sacrifice any performance gains of this patch to make that happen.  You'd just need to restructure the patch.


—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company









view thread (2+ messages)  latest in thread

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: [email protected]
  Cc: [email protected], [email protected], [email protected], [email protected], [email protected], [email protected]
  Subject: Re: XLog size reductions: Reduced XLog record header size for PG17
  In-Reply-To: <[email protected]>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox