Re: Why vacuum?
От | Ross J. Reedstrom |
---|---|
Тема | Re: Why vacuum? |
Дата | |
Msg-id | 20001214095732.A10552@rice.edu обсуждение исходный текст |
Ответ на | AW: Why vacuum? (Zeugswetter Andreas SB <ZeugswetterA@wien.spardat.at>) |
Ответы |
Re: Why vacuum?
|
Список | pgsql-hackers |
On Thu, Dec 14, 2000 at 12:07:00PM +0100, Zeugswetter Andreas SB wrote: > > They all have an overwriting storage manager. The current storage manager > of PostgreSQL is non overwriting, which has other advantages. > > There seem to be 2 answers to the problem: > 1. change to an overwrite storage manager > 2. make vacuum concurrent capable > > The tendency here seems to be towards an improved smgr. > But, it is currently extremely cheap to calculate where a new row > needs to be located physically. This task is *a lot* more expensive > in an overwrite smgr. It needs to maintain a list of pages with free slots, > which has all sorts of concurrency and persistence problems. > Not to mention the recent thread here about people recovering data that was accidently deleted, or from damaged db files: the old tuples serve as redundant backup, in a way. Not a real compelling reason to keep a non-overwriting smgr, but still a surprise bonus for those who need it. Ross
В списке pgsql-hackers по дате отправления: