Feb 09, 2017

nothing about pgSQL is designed for this approach

Interestingly enough, that was a part of the original design from the Berkeley days.


Our proposed approach is to treat the log as normal data managed by the DBMS which will simplify the recovery code and simultaneously provide support for access to the historical data.


3.3. Time Varying Data

POSTQUEL allows users to save and query historical data and versions [KATZ85, WOOD83]. By default, data in a relation is never deleted or updated. Conventional retrievals always access the current tuples in the relation. Historical data can be accessed by indicating the desired time when defining a tuple variable.


Finally, POSTGRES provides support for versions. A version can be created from a relation or a snapshot. Updates to a version do not modify the underlying relation and updates to the underlying relation will be visible through the version unless the value has been modified in the version.

One of the purposes of the much-maligned VACUUM command was to push the historical data to archival (optical) media.

The archival store holds historical records, and the vacuum demon can ensure that ALL archival records are valid.

Jan 25, 2017

A really cool paper to read is The Design of POSTGRES [1] by Stonebraker et al. It's dated by its mentions of things like POSTQUEL, but it's still really interesting to read about the early design of seminal features like the extensible ADT system, from a time when it was still innovative.

1: http://db.cs.berkeley.edu/papers/ERL-M85-95.pdf