"Mikheev, Vadim" wrote:
> Yes.
>
> > I'm a bit concerned that the current storage manager is going to be
> > thrown in the bit bucket without any thought for its benefits. There's
> > 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. Then you've got to figure out strategies
for efficiently deleting old data if you want to. The old postgres was
the
Right Thing, if you want access to time travel.
> 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.
> > storage method etc. There's a whole lot of interesting stuff that can be
> > done with the current storage manager.
>
> Vadim
