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

Greetings,

* Robert Haas (robertmhaas(at)gmail(dot)com) wrote:
> On Fri, Aug 18, 2023 at 12:15 PM Nathan Bossart
> <nathandbossart(at)gmail(dot)com> wrote:
> > I think I agree with Stephen. We routinely make changes that require
> > updates to extensions, and I doubt anyone is terribly wild about
> > maintaining two SLRU systems for several years.
>
> Yeah, maintaining two systems doesn't sound like a good idea.
>
> However, this would be a big change. I'm not sure how we validate a
> change of this magnitude. There are both correctness and performance
> considerations. I saw there had been a few performance results on the
> thread from Thomas that spawned this thread; but I guess we'd want to
> do more research. One question is: how do you decide how many buffers
> to use for each SLRU, and how many to leave available for regular
> data?

Agreed that we'd certainly want to make sure it's all correct and to do
performance testing but in terms of how many buffers... isn't much of
the point of this that we have data in memory because it's being used
and if it's not then we evict it? That is, I wouldn't think we'd have
set parts of the buffer pool for SLRUs vs. regular data but would let
the actual demand drive what pages are in the cache and I thought that
was part of this proposal and part of the reasoning behind making this
change.

There's certainly an argument to be made that our current cache
management strategy doesn't account very well for the value of pages
(eg: btree root pages vs. random heap pages, perhaps) and that'd
certainly be a good thing to improve on, but that's independent of this.
If it's not, then that's certainly moving the goal posts a very long way
in terms of this effort.

Thanks,

Stephen