From: | Adrian Klaver <adrian(dot)klaver(at)aklaver(dot)com> |
---|---|
To: | Phoenix Kiula <phoenix(dot)kiula(at)gmail(dot)com> |
Cc: | John R Pierce <pierce(at)hogranch(dot)com>, PG-General Mailing List <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: Reindex taking forever, and 99% CPU |
Date: | 2014-08-03 13:29:11 |
Message-ID: | 53DE3927.5060609@aklaver.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On 08/02/2014 07:37 PM, Phoenix Kiula wrote:
>> In your original post you said it was stopping on pg_class so now I am
>> confused.
>
>
>
> No need to be confused. The vacuum thing is a bit tricky for laymen
> like myself. The "pg_class" seemed to be associated to this table.
> Anyway, even before the upgrade, the vacuum was stopping at this table
> and taking forever.
>
> The question is: what now. Where can I give you information from?
> IOSTAT I've already shared.
>
> Will the work_mem settings affect the manual REINDEX that's still
> running? What can I do to speed up the REINDEX? Should I change my
> autovacuum settings for this table specifcally (it's the only mammoth
> table in the DB, and our main one)?
Adding to my previous post, some information from the statistic
collector would be useful. See here for more information:
http://www.postgresql.org/docs/9.0/static/monitoring-stats.html#MONITORING-STATS-VIEWS-TABLE
For now the output of:
SELECT * from pg_stat_user_tables where relname='your_table_name';
might prove helpful.
>
> Thanks.
>
>
--
Adrian Klaver
adrian(dot)klaver(at)aklaver(dot)com
From | Date | Subject | |
---|---|---|---|
Next Message | Jeff Janes | 2014-08-04 01:55:17 | Re: Reindex taking forever, and 99% CPU |
Previous Message | Tim Smith | 2014-08-03 11:20:10 | Help needed with postgres stats and math |