Re: [HACKERS] proposals for LLL, part 1
От | Vadim Mikheev |
---|---|
Тема | Re: [HACKERS] proposals for LLL, part 1 |
Дата | |
Msg-id | 35B4C2D2.86050DB9@krs.ru обсуждение исходный текст |
Ответ на | Re: [HACKERS] proposals for LLL, part 1 (Bruce Momjian <maillist@candle.pha.pa.us>) |
Список | pgsql-hackers |
Bruce Momjian wrote: > > > Yes, this is very important question... > > > > In original postgres there was dedicated vacuum process... > > Vacuuming without human administration is possible but > > in any case commit in non-overwriting system requires > > ~2 data block writes (first - to write changes, second - to > > write updated xmin/xmax statuses). In WAL systems only > > 1 data block write required... > > Doesn't a WAL have do an update by writing the old row to a log, then > write the changes to the real table? It is only inserts that have only > one write? I was wrong: WAL systems need in 2 writes (data block and log block) and we need in 3 writes (data block, log block and data block with updated xact statuses). But in commit time WAL have to fsync only log (Oracle places new data there and keep old data in rollback segments) and we have to fsync 2 files. > > > > > Ok, we have to decide two issues about what would we like > > to use in future: > > > > 1. type of storage manager/transaction system - > > > > WAL or non-overwriting. > > If we could just get superceeded row reuse without vacuum, we can stick > with non-overwriting, can't we? I hope... > > > > I personally very like multi-versions... > > OK, now I have to ask what multi-version is. This is our ability to return snapshot of data committed in some point in time. Note, that we are able to return different snapshots to different backends, simultaneously. > > I have to read that Gray book. Did you get my e-mail on it? Thanks and sorry... Yes, this could help me. Do you have my mail address ? Vadim
В списке pgsql-hackers по дате отправления: