AW: Why vacuum?

Поиск
Список
Период
Сортировка
От Zeugswetter Andreas SB
Тема AW: Why vacuum?
Дата
Msg-id 11C1E6749A55D411A9670001FA68796336817E@sdexcsrv1.f000.d0188.sd.spardat.at
обсуждение исходный текст
Ответы Re: Why vacuum?  ("Ross J. Reedstrom" <reedstrm@rice.edu>)
Список pgsql-hackers
> > Yes, postgresql requires vacuum quite often otherwise queries and
> > updates start taking ungodly amounts of time to complete.  If you're
> > having problems because vacuum locks up your tables for too long
> > you might want to check out:
> 
> But why?  I don't know of other databases that need to be 
> 'vacuum'ed.  Do
> all others just do it internaly on a regular basis?
> 
> What am I missing here?

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.

Andreas


В списке pgsql-hackers по дате отправления:

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