Thread

1. Timetravel vs checkpointing and no read-locking

   Michal Mosiewicz <mimo@interdata.com.pl> — 1998-03-11T23:34:04Z

   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
   
   

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

   Vadim Mikheev <vadim@sable.krasnoyarsk.su> — 1998-03-12T07:06:04Z

   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