From: | "Merlin Moncure" <mmoncure(at)gmail(dot)com> |
---|---|
To: | "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | wstrzalka <wstrzalka(at)gmail(dot)com>, pgsql-general(at)postgresql(dot)org |
Subject: | Re: Stats collector eats my CPU |
Date: | 2008-10-08 13:34:28 |
Message-ID: | b42b73150810080634k15aba383u8baf818d6a896972@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On Wed, Oct 8, 2008 at 9:05 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> wstrzalka <wstrzalka(at)gmail(dot)com> writes:
>> the 15483 process is stats collector. At the moment server is almost
>> idle but the stats collector is constantly taking 15-17% of CPU.
>
>> I don't know if it matters at all, but maybe the reason is that the
>> cluster is very large in the term of relation number (many schemes
>> with identical table set).
>
>> select count(*) from pg_class;
>> count
>> --------
>> 257477
>
> Ouch. You might want to consider a schema redesign. Usually, if you've
> got a lot of tables with the same column-set, it's better to combine
> them into one big table with an additional key column.
>
> I'm sure the stats collector runtime is directly tied to having so many
> tables --- it's trying to keep stats on each one of them individually.
Unfortunately there are other competing issues with huge tables, like
long vacuums. There's been some work to mitigate this, but we haven't
turned the corner yet. IMNSHO, though, table partitioning is a
feature that should be used...cautiously.
merlin
From | Date | Subject | |
---|---|---|---|
Next Message | Andy Dale | 2008-10-08 13:42:25 | Re: 8.4 RPMs |
Previous Message | Grzegorz Jaśkiewicz | 2008-10-08 13:24:04 | 8.4 RPMs |