Re: Slow after VACUUM, fast after DROP-CREATE INDEX

Поиск
Список
Период
Сортировка
От ruben
Тема Re: Slow after VACUUM, fast after DROP-CREATE INDEX
Дата
Msg-id 4113B0AC.3070202@superguai.com
обсуждение исходный текст
Ответ на Re: Slow after VACUUM, fast after DROP-CREATE INDEX  (Harald Fuchs <hf0722x@protecting.net>)
Ответы Re: Slow after VACUUM, fast after DROP-CREATE INDEX  ("Scott Marlowe" <smarlowe@qwest.net>)
Список pgsql-general
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
>



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

Предыдущее
От: Stephan Szabo
Дата:
Сообщение: Re: PostgreSQL 7.4.2 allows foreign key violation
Следующее
От: Tom Lane
Дата:
Сообщение: Re: PostgreSQL 7.4.2 allows foreign key violation