On Wed, Apr 29, 2009 at 7:03 PM, Dimitri Fontaine <dfonta...@hi-media.com> wrote: > The idea is to have VACUUM not discard the no more visible tuples but store > them on a specific fork (which you'll want to have on a WORM (cheap) > tablespace, separate issue). > Then you want to be able to associate the tuple xid info with a timestamptz > clock, which could be done thanks to txid and txid_snapshot by means of a > ticker daemon. PGQ from Skytools has such a daemon, a C version is being > prepared for the 3.0 release (alpha1 released).
I think you would use the xid "epoch" which the txid data type stores. You would need a mapping somewhere to translate timestamps to snapshots and the epoch to use for that snapshot. There's a tricky problem of how to find the old tuple values in the new fork. You can't just store them in the same ctid slot because you could have many with the same ctid. I suspect you might be able to get away with making the new fork a btree with the ctid as the key. -- greg -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
