Room: Stream 1
When it comes to the design of the internal components of PostgreSQL, history matters. Earlier designs create ripples that affect later designs.
Extensible indexing created the need for VACUUM, since without VACUUM it is far from obvious how transaction rollback could ever work, at least with GiST and GIN indexes. Transaction rollback that is decoupled from the physical representation of data (compared to traditional designs based on two-phase locking) was necessary even before Postgres added multi-version concurrency control.
This talk will describe a conceptual framework for discussing whether something is an essential part of storing data transactionally from the point of view of users, or whether it is an inessential implementation detail of transaction management and storage, that could in principle be implemented in many different ways. The former can be categorized as belonging to the logical database, while the latter can be categorized as belonging to the physical database.
Recent improvements in how the standard B-Tree index access method performs garbage collection to control MVCC version bloat (authored by the speaker) drew upon these concepts. But almost any improvement to the on-disk representation of either tables or indexes has some kind of tension between the logical and physical database. The talk explores the "logical database, physical database" concepts by discussing this recent work, as well as pending work on free space management in the standard heap table access method.
The following slides have been made available for this session: