AW: Why vacuum?
От | Zeugswetter Andreas SB |
---|---|
Тема | AW: Why vacuum? |
Дата | |
Msg-id | 11C1E6749A55D411A9670001FA68796336817E@sdexcsrv1.f000.d0188.sd.spardat.at обсуждение исходный текст |
Ответы |
Re: Why vacuum?
|
Список | 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 по дате отправления: