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.
Well pg_class is associated with all tables, it is the system catalog
that holds information on tables, among other things.
So what made you think pg_class is involved in your issue?
I suspect you did not just pull that name out of thin air, that it came
from some log or message.
Is that the case?
>
> 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)?
What would be helpful would be some information on the table itself.
What is the schema definition?
What are you storing in the table?
What is its usage pattern, SELECT only, mixed INSERT UPDATE SELECT, etc?
At this point semi-randomly changing settings and operations on this
table would seem to be counter productive.
>
> Thanks.
>
>
--
Adrian Klaver
adrian.klaver@aklaver.com