Epic: Local File Cache Enhancements

[skyzh]

Motivation

The local file cache implemented in file_cache.c is the bridge to close the performance gap between vanilla Postgres and Neon Postgres. Neon fetches data from the page server, which is over the network and cannot be cached in the operating system page cache. The local file cache caches such data. LFC creates a file on the file system and maintains blocks of data inside that file.

https://www.notion.so/neondatabase/Local-File-Cache-What-s-Now-and-What-s-Next-cf8ca77d25f64173a918b059651c8284

Besides the main purpose of being a cache, the LFC also serves several other purposes when it is combined with autoscaling:

• Multi-tenancy. By dynamically resizing the LFC, we can share the local disk space among multiple tenants based on workloads.
• Dynamic shared buffer. Postgres cannot scale its shared buffer when the memory size scales, but we can use LFC to make the working set of Postgres dynamic. We expect the LFC file to be cached in the OS page cache so that it does not issue I/Os to the disk.

DoD

Implementation ideas

• How much does the LFC benefit us compared with a large shared buffer?
• Performance analysis and improvement.
• Physical size control and dynamic resize.

Tasks

- [ ] Raw block device support.
- [ ] Benchmark plans.

Other related tasks and Epics