Re: XLog size reductions: Reduced XLog record header size for PG17
От | Mark Dilger |
---|---|
Тема | Re: XLog size reductions: Reduced XLog record header size for PG17 |
Дата | |
Msg-id | 3496C21F-8836-4341-B8A7-7BB3F611735B@enterprisedb.com обсуждение исходный текст |
Ответ на | XLog size reductions: Reduced XLog record header size for PG17 (Matthias van de Meent <boekewurm+postgres@gmail.com>) |
Список | pgsql-hackers |
> On Jun 20, 2023, at 1:01 PM, Matthias van de Meent <boekewurm+postgres@gmail.com> 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. Couldyou comment on whether perhaps we just need a few versions of that? Perhaps one version where the number of lengthbytes is encoded in the length itself (such as is used for varlena and by Andres' patch) and one where the number oflength bytes is stored elsewhere? You are clearly using the "elsewhere" form, but perhaps you could pull out the logicof that into src/common? In struct XLogRecordBlockHeader.id <http://xlogrecordblockheader.id/>, you are reserving twobits for the size class. (The code comments aren't clear about this, by the way.) Perhaps if the generalized lengthencoding logic could take a couple arguments to represent where and how the size class bits are to be stored, and wherethe 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
В списке pgsql-hackers по дате отправления: