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  (Gaetano Mendola <mendola@bigfoot.com>)
Список 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 по дате отправления:

Предыдущее
От: Oscar Tuscon
Дата:
Сообщение: Re: Sequence Question DOH!
Следующее
От: "Scott Marlowe"
Дата:
Сообщение: Re: Creating blank records with sequential record numbers