Re: [HACKERS] Timetravel vs checkpointing and no read-locking
| От | Vadim B. Mikheev |
|---|---|
| Тема | Re: [HACKERS] Timetravel vs checkpointing and no read-locking |
| Дата | |
| Msg-id | 3507895B.DBE22FBA@sable.krasnoyarsk.su обсуждение исходный текст |
| Ответ на | Timetravel vs checkpointing and no read-locking (Michal Mosiewicz <mimo@interdata.com.pl>) |
| Список | 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 по дате отправления: