Re: XLog size reductions: smaller XLRec block header for PG17

On Mon, Jan 22, 2024 at 5:38 AM Aleksander Alekseev
<aleksander@timescale.com> wrote:
> I don't think that closing CF entries purely due to inactivity is a
> good practice (neither something we did before) as long as there is
> code, it applies, etc. There are a lot of patches and few people
> working on them. Inactivity in a given thread doesn't necessarily
> indicate lack of interest, more likely lack of resources.

If the CF entry doesn't serve the purpose of allowing someone to find
patches in need of review, it's worse than useless. Patches that
aren't getting reviewed should stay in the CF until they do, or until
we make a collective decision that we don't care about or want that
particular patch enough to bother. But patches that are not ready for
review need to get out until such time as they are. Otherwise they're
just non-actionable clutter. And unfortunately we have so much of that
in the CF app now that finding things that really need review is time
consuming and difficult. That REALLY needs to be cleaned up.

In the case of this particular patch, I think the problem is that
there's no consensus on the design. There's not a ton of debate on
this thread, but thread [1] linked in the original post contains a lot
of vigorous debate about what the right thing to do is here and I
don't believe we reached any meeting of the minds. In light of that
lack of agreement, I'm honestly a bit confused why Matthias even found
it worthwhile to submit this on a new thread. I think we all agree
with him that there's room for improvement here, but we don't agree on
what particular form that improvement should take, and as long as that
agreement is lacking, I find it hard to imagine anything getting
committed. The task right now is to get agreement on something, and
leaving the CF entry open longer isn't going make the people who have
already expressed opinions start agreeing with each other more than
they do already.

It looks like I never replied to
https://www.postgresql.org/message-id/20221019192130.ebjbycpw6bzjry4v%40awork3.anarazel.de
but, FWIW, I agree with Andres that applying the same technique to
multiple fields that are stored together (DB OID, TS OID, rel #, block
#) is unlikely in practice to produce many cases that regress. But the
question for this thread is really more about whether we're OK with
using ad-hoc bit swizzling to reduce the size of xlog records or
whether we want to insist on the use of a uniform varint encoding.
Heikki and Andres both seem to favor the latter. IIRC, I was initially
more optimistic about ad-hoc bit swizzling being a potentially
acceptable technique, but I'm not convinced enough about it to argue
against two very smart committers both of whom know more about
micro-optimizing performance than I do, and nobody else seems to
making this argument on this thread either, so I just don't really see
how this patch is ever going to go anywhere in its current form.

--
Robert Haas
EDB: http://www.enterprisedb.com