On Sat, Oct 14, 2023 at 9:43 AM Amit Kapila <amit.kapil...@gmail.com> wrote: > > This and other results shared by you look promising. Will there be any > improvement in workloads related to clog buffer usage?
I did not understand this question can you explain this a bit? In short, if it is regarding the performance then we will see it for all the SLRUs as the control lock is not centralized anymore instead it is a bank-wise lock. BTW, I remember > that there was also a discussion of moving SLRU into a regular buffer > pool [1]. You have not provided any explanation as to whether that > approach will have any merits after we do this or whether that > approach is not worth pursuing at all. > > [1] - https://commitfest.postgresql.org/43/3514/ Yeah, I haven't read that thread in detail about performance numbers and all. But both of these can not coexist because this patch is improving the SLRU buffer pool access/configurable size and also lock contention. If we move SLRU to the main buffer pool then we might not have a similar problem instead there might be other problems like SLRU buffers getting swapped out due to other relation buffers and all and OTOH the advantages of that approach would be that we can just use a bigger buffer pool and SLRU can also take advantage of that. But in my opinion, most of the time we have limited page access in SLRU and the SLRU buffer access pattern is also quite different from the relation pages access pattern so keeping them under the same buffer pool and comparing against relation pages for victim buffer selection might cause different problems. But anyway I would discuss those points maybe in that thread. -- Regards, Dilip Kumar EnterpriseDB: http://www.enterprisedb.com
