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?  (Alfred Perlstein <bright@wintelcom.net>)
Список 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 по дате отправления:

Предыдущее
От: "Michael Richards"
Дата:
Сообщение: Re: (Updated) Table File Format
Следующее
От: Daniele Orlandi
Дата:
Сообщение: Re: Why vacuum?