Re: Storage Manager (was postgres 7.2 features.)

Also, does WAL offer instantaneous crash recovery like no-overwrite?


"Mikheev, Vadim" wrote:
> 
> > > > some stuff I want to do with it like resurrecting time travel,
> > >
> > > Why don't use triggers for time-travel?
> > > Disadvantages of transaction-commit-time based time travel
> > > was pointed out a days ago.
> >
> > Triggers for time travel is MUCH less efficient. There is no copying
> > involved either in memory or on disk with the original postgres time
> > travel, nor is there any logic to be executed.
> 
> With the original TT:
> 
> - you are not able to use indices to fetch tuples on time base;
> - you are not able to control tuples life time;
> - you have to store commit time somewhere;
> - you have to store additional 8 bytes for each tuple;
> - 1 sec could be tooo long time interval for some uses of TT.
> 
> And, btw, what could be *really* very useful it's TT + referential integrity
> feature. How could it be implemented without triggers?
> 
> Imho, triggers can give you much more flexible and useful TT...
> 
> Also note that TT was removed from Illustra and authors wrote that
> built-in TT could be implemented without non-overwriting smgr.
> 
> > > It was mentioned here that triggers could be used for async
> > > replication, as well as WAL.
> >
> > Same story. Major inefficency. Replication is tough enough without
> > mucking around with triggers. Once the trigger executes you've got
> > to go and store the data in the database again anyway. Then figure
> > out when to delete it.
> 
> What about reading WAL to get and propagate changes? I don't think that
> reading tables will be more efficient and, btw,
> how to know what to read (C) -:) ?
> 
> Vadim