3 ms·
Design goals of Postgres (via 1995 paper) [pdf]
- craigkerstiens 10y agoThe tldr; is in 1995 Postgres was focused on enabling faster rendering of shapes/graphics at about 1-2 frames per second.
- grzm 10y agoThanks for posting this PDF! I've wanted to read this for a while and this provided me with the opportunity to do it now. > focused on enabling faster rendering This is indeed provided as an example for their motivation for their first goal of supporting complex objects, and it's an interesting anecdote. There are 5 additional design goals as well.
- grzm 10y agoI think it's pretty cool that back in 1995 Stonebraker and Rowe were looking at effectively "append-only" architecture which have recently come to prominence in things like Kafka and Datomic. Interesting excerpts: 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 rela- tion 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.