Re: Vacuum Daemon
От | Bruce Momjian |
---|---|
Тема | Re: Vacuum Daemon |
Дата | |
Msg-id | 200206300212.g5U2CfP22909@candle.pha.pa.us обсуждение исходный текст |
Ответ на | Re: Vacuum Daemon (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
Tom Lane wrote: > "J. R. Nield" <jrnield@usol.com> writes: > >> I do not think that is the case; and anyway we've pretty much rejected > >> Vadim's notion of going to an Oracle-style UNDO buffer. > > > Could someone point me to this discussion, or summarize what the problem > > was? > > I'm too lazy to dig through the archives at the moment, but the main > points were (a) a finite-size UNDO buffer chokes on large transactions > and (b) the Oracle approach requires live transaction processing to > do the cleanup work that our approach can push off to hopefully-not- > time-critical vacuum processing. > > UNDO per se doesn't eliminate VACUUM anyhow; it only reclaims space > from tuples written by aborted transactions. If you want to get rid > of VACUUM then you need another way to get rid of the old versions of > perfectly good committed tuples that are obsoleted by updates from > later transactions. That essentially means you need an overwriting > storage manager, which is a concept that doesn't mix well with MVCC. > > Oracle found a solution to that conundrum, but it's really not obvious > to me that their solution is better than ours. Also, they have > patents that we'd probably run afoul of if we try to imitate their > approach too closely. Don't forget reclaiming space from transactions that delete tuples. UNDO doesn't help there either. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
В списке pgsql-hackers по дате отправления: