Re: Stats collector eats my CPU

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

In response to

Responses

Browse pgsql-general by date

  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