Re: REINDEX takes half a day (and still not complete!)

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: REINDEX takes half a day (and still not complete!)
Дата
Msg-id 34CE0668-2A83-4BE4-B191-86871C2F8334@gmail.com
обсуждение исходный текст
Ответ на Re: REINDEX takes half a day (and still not complete!)  (Phoenix Kiula <phoenix.kiula@gmail.com>)
Ответы Re: REINDEX takes half a day (and still not complete!)
Список pgsql-performance
On Apr 17, 2011, at 11:30 AM, Phoenix Kiula <phoenix.kiula@gmail.com> wrote:
> Sorry, rejuvenating a thread that was basically unanswered.
>
> I closed the database for any kinds of access to focus on maintenance
> operations, killed all earlier processes so that my maintenance is the
> only stuff going on.
>
> REINDEX is still taking 3 hours -- and it is still not finished!
>
> Similarly, if I cancel the REINDEX and issue a VACUUM ANALYZE VERBOSE,
> this too seems to just hang there on my big table.
>
> I changed the maintenance_work_men to 2GB for this operation. It's
> highly worrisome -- the above slow times are with 2GB of my server
> dedicated to Postgresql!!!!
>
> Surely this is not tenable for enterprise environments? I am on a
> 64bit RedHat server with dual CPU Intel Woodcrest or whatever that was
> called. Postgres is 8.2.9.
>
> How do DB folks do this with small maintenance windows? This is for a
> very high traffic website so it's beginning to get embarrassing.
>
> Would appreciate any thoughts or pointers.

An upgrade would probably help you a lot, and as others have said it sounds like your hardware is failing, so you
probablywant to deal with that first. 

I am a bit surprised, however, that no one seems to have mentioned using CLUSTER rather than VACUUM or REINDEX.
Sometimesthat's worth a try... 

...Robert

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

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: big distinct clause vs. group by
Следующее
От: Paul Pierce
Дата:
Сообщение: Issue with partition elimination