Re: Poor Performance on a table

From: Pallav Kalva <pkalva(at)deg(dot)cc>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-performance(at)postgresql(dot)org
Subject: Re: Poor Performance on a table
Date: 2004-12-02 19:54:19
Message-ID: 41AF72EB.1070900@deg.cc
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

Tom Lane wrote:

>Pallav Kalva <pkalva(at)deg(dot)cc> writes:
>
>
>> I have a table in my production database which has 500k rows and
>>from the pg_class it shows the number of "relpages" of
>>around 750K for this table, the same table copied to a test database
>>shows "relpages" as 35k. I run vacuumdb on the whole
>>database (not on the table individually but the whole database) daily.
>>
>>
>
>You're obviously suffering serious table bloat :-(. Depending on how
>heavy the update traffic on that table is, it might be that once-a-day
>vacuum is simply not often enough. Another likely problem is that you
>need to increase the FSM settings (how big is your whole database?)
>
Yes, you are right this table is heavily updated, the whole database
size is of 1.5 gigs, right now i have default fsm settings how much
should i increase max_fsm_pages and max_fsm_relations to ?

>
>
>
>> Is there any way to fix this problem ?
>>
>>
>
>VACUUM FULL will fix the immediate problem. You might well find CLUSTER
>to be a faster alternative, though.
>
>
I am hesitant to do vacuum full on the table because it is one of the
crucial table in our application and we cant afford to have exclusive
lock on this table for long time. we can afford not to have writes and
updates but we need atleast reads on this table .
How does CLUSTER benefit me ? excuse me, i am new to this feature.

> regards, tom lane
>
>
>

In response to

Responses

Browse pgsql-performance by date

  From Date Subject
Next Message Tom Lane 2004-12-02 20:10:49 Re: Poor Performance on a table
Previous Message Tom Lane 2004-12-02 19:42:37 Re: [PERFORM] scalability issues on win32