Re: SLRUs in the main buffer pool - Page Header definitions

On Fri, Jun 24, 2022 at 03:45:34PM -0700, Andres Freund wrote:

> 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.

Alright, I agree with the metapage having the necessary info. In
this case, we can rely on the hierarchy to determine the type of header.
Given we do not have an usecase requiring the flag, we should not
consume it at this point.

> > 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.

We did think through a universal page header concept that included just
the pd_lsn, pd_checksum, pd_flags and pulling in pd_pagesize_version and other
fields as the non-uniform members for SLRU. Unfortunately, there is a gap of
48 bits after pd_flags which makes it challenging with today's header. I am
leaning towards the standard page header for now and revisiting the universal/uniform
page header and AM changes in a separate effort. The push down to AM is an
interesting concept and should be worthwhile following up on.

> > 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.

To be honest, given the nature of changes, I would prefer to have it
done in one major version release than have it be split into multiple
efforts. The value add really comes in from the consistency checks that
can be done and which are non-existent for SLRU today.