>From time to time the old Time Travel postgres functionality is
mentioned.
When it is mentioned, somebody usually says "Yeah well you can implement
it
just as well with triggers therefore it's redundant" and the doco says
"New
features such as triggers allow one to mimic the behavior of time travel
when
desired, without incurring the overhead when it is not needed (for most
users,
this is most of the time).
This seems to fail to take into account the original design which was
to take advantage of a different style of storage manager, that doesn't
have an undo log. Unless I'm missing something, postgres is indeed still
"incurring the overhead" of time travel, but losing the feature.
In fact, if you have fsync turned on for full safety, the postgres
performance is going to be bad compared to a regular design
storage manager.
On the other hand the postgres storage manager had the advantage of time
travel because it does not update in place.
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.".
Now since I believe the postgres storage manager does not replace
records in place when updated, 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.
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.