Обсуждение: Re: [HACKERS] proposals for LLL, part 1
Stan Brown wrote: > > > > >First, PostgreSQL is multi-version system due to its > >non-overwriting storage manager. And so, first proposal is use > >this feature (multi-versioning) in LLL implementation. > > > > I must ask one basic question here. Since we dleted tme travel, and the > non-overwriting storage manager is no longer required, should we at > least discuss changing that, either as a part of the LLC work, or prior > to it. > > I think one of the primary reasons to do so would be to eliminate > vacumm. Would this not be better for a system that needs to be up > 24x7x365? 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... 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. 2. type of concurrency/consistency control - Locking or multi-versions. These are quite different issues! Oracle is WAL and multi-version system! We could implement multi-version control now and switch to WAL latter... If we decide that locking is ok for concurrency/consistency then it's better to switch to WAL before implementing LLL. I personally very like multi-versions... Comments/votes..? Vadim P.S. I'll be off-line up to the monday...
> 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... > > 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. Can you explain WAL. I understand locking vs. multi-version. -- Bruce Momjian | 830 Blythe Avenue maillist@candle.pha.pa.us | Drexel Hill, Pennsylvania 19026 + If your life is a hard drive, | (610) 353-9879(w) + Christ can be your backup. | (610) 853-3000(h)
Bruce Momjian wrote: > > > > > 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. > > Can you explain WAL. I understand locking vs. multi-version. Write Ahead Log - log of changes. Vadim
> 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? > > 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. > > 2. type of concurrency/consistency control - > > Locking or multi-versions. If we could just get superceeded row reuse without vacuum, we can stick with non-overwriting, can't we? > > These are quite different issues! > > Oracle is WAL and multi-version system! > > We could implement multi-version control now and switch > to WAL latter... > > If we decide that locking is ok for concurrency/consistency > then it's better to switch to WAL before implementing LLL. > > I personally very like multi-versions... OK, now I have to ask what multi-version is. I have to read that Gray book. Did you get my e-mail on it? -- Bruce Momjian | 830 Blythe Avenue maillist@candle.pha.pa.us | Drexel Hill, Pennsylvania 19026 + If your life is a hard drive, | (610) 353-9879(w) + Christ can be your backup. | (610) 853-3000(h)
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
On Fri, Jul 17, 1998 at 01:00:10PM +0800, Vadim Mikheev wrote: > 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... Then the arguments are clearly in favor of WAL. > Oracle is WAL and multi-version system! While Oracle has some faults (or more) I agree with that choice. > We could implement multi-version control now and switch > to WAL latter... Once again I fully agree. > I personally very like multi-versions... Me too. Michael -- Dr. Michael Meskes meskes@online-club.de, meskes@debian.org Go SF49ers! Go Rhein Fire! Use Debian GNU/Linux!