Greetings, * Robert Haas (robertmh...@gmail.com) wrote: > On Fri, Aug 18, 2023 at 12:15 PM Nathan Bossart > <nathandboss...@gmail.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
signature.asc
Description: PGP signature
