Skip site navigation (1) Skip section navigation (2)

Re: 'TID index'

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Ross J(dot) Reedstrom" <reedstrm(at)rice(dot)edu>
Cc: Simon Riggs <simon(at)2ndquadrant(dot)com>,"Jim C(dot) Nasby" <decibel(at)decibel(dot)org>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: 'TID index'
Date: 2004-09-26 06:17:39
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
"Ross J. Reedstrom" <reedstrm(at)rice(dot)edu> writes:
> ... So, all this append-only writing leads to files with lots of dead
> tuples, so the vacuum command was added to reclaim space.

Actually, I believe the original Postgres design envisioned that no
tuple would ever be permanently deleted: the idea was that you would
always be able to query the database state as of past times as well
as the present instant.  Stonebraker intended to use the WORM drive as
the repository for dead tuples that might be needed to answer such
historical queries.  The "vacuum cleaner" was originally a background
process that pushed dead tuples from magnetic disk to WORM storage.
Its current manifestation is dumbed-down from that, since we only
delete rows and make no attempt to save them somewhere else --- but
it was always an integral part of the system design.

It's quite entertaining to read "The design of the POSTGRES storage
system" (ERL-M87-06, available at
and compare it to where we are now.  There is just enough similarity
that it's obviously the ancestor of our present code ... but there is
also a lot in that paper that has left *no* trace in our present code.
I would love to know just how much of the paper actually got implemented
and then discarded, and how much never got beyond the arm-waving stage.

			regards, tom lane

In response to


pgsql-hackers by date

Next:From: Dennis BjorklundDate: 2004-09-26 06:46:49
Subject: Re: Get rid of Money
Previous:From: Tom LaneDate: 2004-09-26 05:48:01
Subject: Re: Get rid of Money

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group