Content-Type: text/plain;
	charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.700.6.1.1\))
Subject: Re: XLog size reductions: Reduced XLog record header size for PG17
From: Mark Dilger <mark.dilger@enterprisedb.com>
In-Reply-To: <CAEze2WgcW5SkPO_TGTqirRcCS_FN0xEZqUsXDE6pPz2TYzXQBA@mail.gmail.com>
Date: Wed, 5 Jun 2024 08:12:47 -0700
Cc: PostgreSQL Hackers <pgsql-hackers@postgresql.org>,
 Heikki Linnakangas <hlinnaka@iki.fi>,
 Robert Haas <robertmhaas@gmail.com>,
 Dilip Kumar <dilipbalaut@gmail.com>,
 Andres Freund <andres@anarazel.de>
Content-Transfer-Encoding: quoted-printable
Message-Id: <3496C21F-8836-4341-B8A7-7BB3F611735B@enterprisedb.com>
References: <CAEze2WgcW5SkPO_TGTqirRcCS_FN0xEZqUsXDE6pPz2TYzXQBA@mail.gmail.com>
To: Matthias van de Meent <boekewurm+postgres@gmail.com>
Archived-At: <https://www.postgresql.org/message-id/3496C21F-8836-4341-B8A7-7BB3F611735B%40enterprisedb.com>
Precedence: bulk


> On Jun 20, 2023, at 1:01 PM, Matthias van de Meent =
<boekewurm+postgres@gmail.com> wrote:
>=20
> 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.


=E2=80=94
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company