Room: DMS 1140
PostgreSQL introduced the concept of the Table Access Method API in version 12. Originally intended as a "storage plugin framework", this API was intended to allow additional and new PostgreSQL storage engines which could cover more potential use cases that are optimized for different hardware architectures and different data models. The current design of the API implies a new engine will re-use pretty much of the existing PostgreSQL internals including buffer manager, block-level WAL, tuple identifiers, transaction identifiers, and enumerated snapshots. However, these internals cause many shortcomings by themselves such as sub-optimal multi-core scalability, significantly increased WAL traffic, etc. Is it possible to grow beyond these architectural limitations? How difficult is it? What does a potential cloud-native Postgres look like? This talk will discuss a small set of proposed patches that brings table access method API to a new level of power and flexibility. This "patchset" allows implementing anti-buffering instead of buffer mapping, row-level WAL instead of block-level WAL, arbitrary row identifiers in index-organized tables, scalable CSN snapshots, and so on.