Re: Poor Performance on a table - Mailing list pgsql-performance

From Pallav Kalva
Subject Re: Poor Performance on a table
Date
Msg-id 41AF72EB.1070900@deg.cc
Whole thread Raw
In response to Re: Poor Performance on a table  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Poor Performance on a table
Re: Poor Performance on a table
List pgsql-performance
Tom Lane wrote:

>Pallav Kalva <pkalva@deg.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
>
>
>



pgsql-performance by date:

Previous
From: Tom Lane
Date:
Subject: Re: [pgsql-hackers-win32] scalability issues on win32
Next
From: Tom Lane
Date:
Subject: Re: Poor Performance on a table