Re: New WAL record to detect the checkpoint redo location

From: Thomas Munro <thomas(dot)munro(at)gmail(dot)com>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Andres Freund <andres(at)anarazel(dot)de>, Dilip Kumar <dilipbalaut(at)gmail(dot)com>, Heikki Linnakangas <hlinnaka(at)iki(dot)fi>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: New WAL record to detect the checkpoint redo location
Date: 2023-10-11 21:42:39
Message-ID: CA+hUKG+=3u8EBpGuFwZ8E2Xm7AHBso7FB771e_z0vbGhCVTc1g@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Oct 10, 2023 at 11:33 AM Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> On Mon, Oct 9, 2023 at 4:47 PM Andres Freund <andres(at)anarazel(dot)de> wrote:
> > I think we might be able to speed some of this up by pre-compute values so we
> > can implement things like bytesleft / UsableBytesInPage with shifts. IIRC we
> > already insist on power-of-two segment sizes, so instead of needing to divide
> > by a runtime value, we should be able to shift by a runtime value (and the
> > modulo should be a mask).
>
> Huh, is there a general technique for this when dividing by a
> non-power-of-two? The segment size is a power of two, as is the page
> size, but UsableBytesIn{Page,Segment} are some random value slightly
> less than a power of two.

BTW in case someone is interested, Hacker's Delight (a book that has
come up on this list a few times before) devotes a couple of chapters
of magical incantations to this topic. Compilers know that magic, and
one thought I had when I first saw this discussion was that we could
specialise the code for the permissible wal segment sizes. But nuking
the variable sized page headers sounds better.

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2023-10-11 21:49:37 Re: Regarding Postgresql Transaction isolation
Previous Message David Rowley 2023-10-11 21:39:26 Re: Add null termination to string received in parallel apply worker