> > > 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