Timetravel vs checkpointing and no read-locking

Timetravel is gone but postgres is still non-overwriting system:
both old and new versions of a changed tuple are in place.

Michal Mosiewicz wrote:

Hello,

I was just reading new KUBL documentation (www.kubl.com) and I found an
interesting feature there.

Shortly speaking, it allows for checkpointing and reading without
locking at all. I was thinking about something similiar in Postgres.
While there was timetravel it was relatively easy to implement, but now
we are going out of timetravel code.

However, maybe it would be nice to leave some of the code. As far as I
understand kubl (and probably other databases) allows for lock-free
quering before-checkpoint data. For me it seems like a very powerful
feature. Especially if you have a database that is fed constantly and
you still want to retrieve large statistical data that would lock the
table for too long. By using checkpoint, one may query checkpointed data
without interrupting updating processes.

So what if we leave some part of this code to give us more isolation of
historical data. I think it's easier to implement than page/row level
locking, but it may increase performance of frequently updated
databases.

Of course I don't mean timetravel in previous sense. This was way too
expensive. But having two versions of each record, i.e. a checkpointed
version and working version seems to be cheap.

Vadim