SLRU improvements

Mailing List Threads

Below is a list of recent mailing list threads covering SLRU improvements:

• XID formatting and SLRU refactorings. The work has completed.

• SLRU optimization - configurable buffer pool and partitioning the SLRU lock. The work is ongoing.

• SLRUs in the main buffer pool. The thread is inactive.

• Proposal to add page headers to SLRU pages. The work is ongoing.

Ideas

Many ideas have been proposed and worked on. This section provides a summary of the discussions.

64-bit identifiers

In XID formatting and SLRU refactorings, to avoid the wraparound headache, all 32-bit identifiers have been upgraded to 64-bit. No change has been made to the SLRU mechanisms. The work has completed.

Add the buffer page header to each SLRU page

In SLRUs in the main buffer pool, among many ideas proposed in the thread, it proposed to add a page header to each SLRU page. Rishu Bagga, Andres Freund, Robert Hass, and Stephen Frost discussed over this topic and agreed that adding page headers to SLRU pages are beneficial for the long run and using the existing buffer page header is preferable.

The idea has been revived by Proposal to add page headers to SLRU pages. The benefit of adding page headers includes:

• It allows checksum to be enabled for SLRU pages as well.
• Page LSN is tracked within the page, and removes the need of the ad-hoc LSN group structure within the SLRU control data.
• It paves the way for further enhancements, e.g. encryption, combining SLRU caches with the main buffer pool.

Move SLRU to the main buffer pool

This is the main topic of SLRUs in the main buffer pool. The discussion lacked focus and clarity. Here is a summary of opinions:

• There should be a single pool for buffers and SLRU caches.
• Different eviction strategies between buffer and SLRU caches may be beneficial.
• Improvements on per-SLRU latch may still be needed to reduce lock contention.

Lock partition

This is the main topic of SLRU optimization - configurable buffer pool and partitioning the SLRU lock. The idea is straightforward. Instead of using a single latch for the entire SLRU cache, partition the cache into multiple banks and use a separate latch for each bank. Due to performance considerations, the design also allows using a single latch for a group of banks to reduce the number of latches.