Re: REINDEX takes half a day (and still not complete!) - Mailing list pgsql-performance

From Robert Haas
Subject Re: REINDEX takes half a day (and still not complete!)
Date
Msg-id 34CE0668-2A83-4BE4-B191-86871C2F8334@gmail.com
Whole thread Raw
In response to Re: REINDEX takes half a day (and still not complete!)  (Phoenix Kiula <phoenix.kiula@gmail.com>)
Responses Re: REINDEX takes half a day (and still not complete!)  (Greg Smith <greg@2ndQuadrant.com>)
List 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 by date:

Previous
From: Robert Haas
Date:
Subject: Re: big distinct clause vs. group by
Next
From: Paul Pierce
Date:
Subject: Issue with partition elimination