No i am referring to time travel within a transaction, not outside. On 10/31/07, Hans-Juergen Schoenig <[EMAIL PROTECTED]> wrote: > > hello ... > > i guess there is no formal proposal yet but there are some ideas around > and some major challenges have been discussed already. > i think simon riggs was planning to work on it in the future. > the basic idea here is to have the option to create a "snapshot" which > then stays in the database. the main challenge is that PostgreSQL > should not keep all version of a row since the snapshot but VACUUM should > be able to clean out all rows which are not seen by any snapshot or any > ongoing transaction. > this should be a quite fancy solution which is quite space efficient. > > internally we had the idea of tweaking VACUUM a little: > > VACUUM BEFORE timestamp; > and ... > SET current_snapshot TO '2007-10-10 ...'; > > this would allow a queries to use any snapshot after the timestamp defined > by VACUUM (if data is around). > the downside here: you might potentially eat up more space. > flashback data should be read only, of course. > > best regards, > > hans > > > > On Oct 31, 2007, at 11:31 AM, Gokulakannan Somasundaram wrote: > > Hi, > I went through the mailing list and couldn't get answer to the > question. > > a) Is there a proposal in place for going back in time within a > transaction? > > > > -- > Thanks, > Gokul. > CertoSQL Project, > Allied Solution Groups. > (www.alliedgroups.com) > > > > > -- > Cybertec Schönig & Schönig GmbH > Gröhrmühlgasse 26, 2700 Wiener Neustadt > Tel: +43/1/205 10 35 / 340 > www.postgresql.at, www.cybertec.at > > >
-- Thanks, Gokul. CertoSQL Project, Allied Solution Groups. (www.alliedgroups.com)
