Re: [HACKERS] An introduction and a plea ... - Mailing list pgsql-hackers

From Hannu Krosing
Subject Re: [HACKERS] An introduction and a plea ...
Date
Msg-id 389F30C9.915DDC4A@tm.ee
Whole thread Raw
In response to An introduction and a plea ...  (Emmanuel Charpentier <charpent@bacbuc.dyndns.org>)
List pgsql-hackers
Chris Bitmead wrote:
> 
> Hannu Krosing wrote:
> 
> > > >     The same kind of file could be used for re_introducing time-travel in an
> > > >     efficient way.
> > >
> > > How?
> >
> > By writing (TID,TIMESTAMP) tuples there and using that info to retrieve tuples
> > active at specified time by examinimg TIDs in "deleted" tuples.
> > As bot TID and TIMESTAMP should be monotonuously growing again binary search
> > can be used on retrieve and inserts are append-only (meaning fast)
> 
> But since we are already storing all the time travel stuff already in
> the storage pages do we need this to reinstate time travel?

If we want to query for old tuples by wallclock time (which is not stored) and 
not only by transaction-id (which are) we need something to go from wc-time to
tid
and back.

> Also if you reinstate time travel this way it will only work for people using 
> this odbms feature.
> Wouldn't it be better to reinstate the old timetravel so it works for
> everyone?

It would be probably better to do it under another set, probably at dbinit 
(or createdb) time.

so maybe 

set TIME_TRAVEL to 'on';
CREATE DATABASE TIME_TRAVELLERS_DB;

would create a database that can use the time-travel features.

It could of course be included in the db create statement:

CREATE DATABASE TIME_TRAVELLERS_DB WITH TIME_TRAVEL='ON';

BTW, have you considered making OO a per-database feature or at least the 
default being settable when creating the database.

-----------------------
Hannu


pgsql-hackers by date:

Previous
From: Oleg Bartunov
Date:
Subject: network_ops in 7.0 and pg_dump question
Next
From: Bruce Momjian
Date:
Subject: Re: [HACKERS] network_ops in 7.0 and pg_dump question