Re: [HACKERS] Timetravel vs checkpointing and no read-locking - Mailing list pgsql-hackers

From Vadim B. Mikheev
Subject Re: [HACKERS] Timetravel vs checkpointing and no read-locking
Date
Msg-id 3507895B.DBE22FBA@sable.krasnoyarsk.su
Whole thread Raw
In response to Timetravel vs checkpointing and no read-locking  (Michal Mosiewicz <mimo@interdata.com.pl>)
List pgsql-hackers
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

pgsql-hackers by date:

Previous
From: Hal Snyder
Date:
Subject: Re: [HACKERS] port/getrusage.c?
Next
From: Hal Snyder
Date:
Subject: Re: [HACKERS] port/getrusage.c?