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

Re: Reviving Time Travel (was Re: 'TID index')

From: "Simon Riggs" <simon(at)2ndquadrant(dot)com>
To: "Hannu Krosing" <hannu(at)tm(dot)ee>, "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: "Ross J(dot) Reedstrom" <reedstrm(at)rice(dot)edu>,"Simon Riggs" <simon(at)2ndquadrant(dot)com>,"Jim C(dot) Nasby" <decibel(at)decibel(dot)org>, <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Reviving Time Travel (was Re: 'TID index')
Date: 2004-09-28 07:26:00
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
>Hannu Krosing [mailto:hannu(at)tm(dot)ee]
> On P, 2004-09-26 at 09:17, Tom Lane wrote:
> > "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.
> We are now getting back to the point where the "background process" part
> is true again - how hard would it be to modify vacuum to write recalimed
> tuples to somewhere (network pipe, WORM drive, other DB).
> It seems that in addition to writing deleted tuples out to history DB
> and making create and delete transaction ids explicitly visible (and do
> something(tm) about the transaction id wraparound while at it), the only
> thing left to do is some kind of transaction time log - and voila! we
> have the original Time Travel feature back - a great feature for
> resolving both "audit trail" and "clumsy dba" problems. 
> The modern WORM drive equivalent is an IDE(-RAID) disk with its very
> tape-like access profile (3+ hours to write full 300GB disk, random
> access order(s) of magnitude slower than sequential);
> So if someone is looking for a project, this seems to be something that
> is both theoretically possible and also theoretically useful ;)

Yes, I thought that too - but not for me, not now.

Look here:
for similar

Best Regards, Simon Riggs

In response to


pgsql-hackers by date

Next:From: Szima GáborDate: 2004-09-28 08:22:05
Subject: pg_stat_activity EXISTS bug in 8.0.0beta3
Previous:From: Serguei A. MokhovDate: 2004-09-28 05:51:06
Subject: Re: Compiling from CVS: undefined reference to

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