Re: SLRUs in the main buffer pool - Page Header definitions - Mailing list pgsql-hackers

Hi,

On 2022-06-24 22:19:33 +0000, Shawn Debnath wrote:
> On Thu, Jun 23, 2022 at 06:06:48PM -0700, Andres Freund wrote:
>
> > > You are correct that we wouldn’t need to rely on the pd_flag bit to
> > > determine page type for any access to a page where we come top down
> > > following the hierarchy. However, for the purpose of debugging “from the
> > > bottom up” it would be critical to know what type of page is being read in a
> > > system with multiple page header types.
> >
> > That doesn't seem to justify using a bit on the page. Wouldn't it suffice to
> > add such information to the BufferDesc?
>
> The goal for the bit in pd_flags is to help identify what page header
> should be present if one were to be looking at the physical page outside
> of the database. One example that comes to mind is pg_upgrade.  There
> are other use cases where physical consistency checks could be applied,
> again outside of a running database.

Outside the database you'll know the path to the file, which will tell you
it's not another kind of relation.

This really makes no sense to me. We don't have page flags indicating whether
a page is a heap, btree, visibility, fms whatever kind of page either. On a
green field, it'd make sense to have such information in a metapage at the
start of each relation - but not on each page.


> On Thu, Jun 23, 2022 at 04:27:33PM -0400, Robert Haas wrote:
>
> > I think that it's not worth introducing a new page header format to
> > save 10 bytes per page. Keeping things on the same format is likely to
> > save more than the minor waste of space costs.
>
> Yeah, I think we are open to both approaches, though we believe it would
> be cleaner to get started with a targeted page header for the new code.
> But do understand having to understand/translate/deal with two page
> header types might not be worth the savings in space.

Not sure if that changes anything, but it's maybe worth noting that we already
have some types of pages that don't use the full page header (at least
freespace.c, c.f. buffer_std argument to MarkBufferDirtyHint()). I can see an
argument for shrinking the "uniform" part of the page header, and pushing more
things down into AMs. But I think that'd need to change the existing code, not
just introduce something new for new code.


> Stepping back, it seems like folks are okay with introducing a page
> header to current SLRU components and that we are leaning towards
> sticking with the default one for now. We can proceed with this
> approach, and if needed, change it later if more folks chime in.

I think we're clearly going to have to do that at some point not too far
away. There's just too many capabilities that are made harder by not having
that information for SLRU pages. That's not to say that it's a prerequisite to
moving SLRUs into the buffer pool (using a hack like Thomas did until the page
header is introduced). Both are complicated enough projects on their own. I
also could see adding the page header before moving SLRUs in the buffer pool,
there isn't really a hard dependency.

Greetings,

Andres Freund