Thread: Timetravel vs checkpointing and no read-locking

Timetravel vs checkpointing and no read-locking

From
Michal Mosiewicz
Date:
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.

Mike

--
WWW: http://www.lodz.pdi.net/~mimo  tel: Int. Acc. Code + 48 42 148340
add: Michal Mosiewicz  *  Bugaj 66 m.54 *  95-200 Pabianice  *  POLAND

Re: [HACKERS] Timetravel vs checkpointing and no read-locking

From
"Vadim B. Mikheev"
Date:
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