Chris Bitmead wrote:
>
> Now in the documentation it mentioned removing time travel because
> "performance impact, storage size, and a pg_time file which
> grows toward infinite size in a short period of time.".
In the time this was written 200MB disk was a big disk.
> Now since I believe the postgres storage manager does not replace
> records in place when updated,
Yes, it's true at least for 6.5.3 (I've written a small script that
extracts the old/hidden tuples) and I'm pretty sure that for 7.x too
perhaps it is the removal of pg_time (which i think recorded correspondence
between transaction ids and timestamps) that gives the big performance win.
> I can't see how it is different to
> having the time travel feature with vacuum configured to remove
> all old records immediately. I don't know what the pg_time file
> is.
I guss it could be just a add_only, monotonuously growing 'tape'-type file,
suitable for being searched using binary search. So really not nearly as
much overhead as would be a regular pg table with two indexes.
> Have I missed something about why taking out time travel has
> improved performance, as opposed to simply making immediate
> vacuum the default? Clearly the performance of triggers as an
> alternative is going to suck very badly, since the postgres
> storage manager was built specially from the ground up to
> support time travel with its non-update semantics, and it
> still has these characteristics.
Implementing time-travel with triggers wil actually give us double
time-travel, on hidden and one visible ;)
