Re: Slow after VACUUM, fast after DROP-CREATE INDEX
От | Scott Marlowe |
---|---|
Тема | Re: Slow after VACUUM, fast after DROP-CREATE INDEX |
Дата | |
Msg-id | 1091816272.27166.217.camel@localhost.localdomain обсуждение исходный текст |
Ответ на | Re: Slow after VACUUM, fast after DROP-CREATE INDEX (ruben <ruben20@superguai.com>) |
Ответы |
Re: Slow after VACUUM, fast after DROP-CREATE INDEX
|
Список | pgsql-general |
Unfortunately, the administrative overhead in 7.1.3 is noticeably higher than it is in 7.4. The overhead should be lowered even more in 8.0 with the integration of the autovacuum daemon into the backend process. On Fri, 2004-08-06 at 10:24, ruben wrote: > Thanks Harald, i'm running PostgreSQL 7.1.3. > > > > Harald Fuchs wrote: > > > In article <411296B5.6000204@superguai.com>, > > ruben <ruben20@superguai.com> writes: > > > > > >>Today, one of the processes running daily took 4 hours when it takes > >>about 5 minutes. After a VACCUM ANALYZE of the affected tables it took > >>the same to finish, then I recreated (drop and create) the index of > >>the affected table and the process when again fast. My question is, > >>isn't enough to run a VACCUM to optimize a table and its indexes? Is > >>it advisable to recreate indexes from time to time? > > > > > > This was necessary in PostgreSQL up to 7.3.x, but 7.4.x is supposed to > > fix that. What version are you running? > > > > > > ---------------------------(end of broadcast)--------------------------- > > TIP 7: don't forget to increase your free space map settings > > > > > > ---------------------------(end of broadcast)--------------------------- > TIP 5: Have you checked our extensive FAQ? > > http://www.postgresql.org/docs/faqs/FAQ.html >
В списке pgsql-general по дате отправления: