Re: Wrong Stats and Poor Performance - Mailing list pgsql-performance

John A Meinel wrote:

> Pallav Kalva wrote:
>
>> Hi Everybody.
>>
>>      I have a table in my production database which gets updated
>> regularly and the stats on this table in pg_class  are totally
>> wrong.  I used to run vacuumdb on the whole database daily once and
>> when i posted the same problem of wrong stats in the pg_class most of
>> them from this list and also from postgres docs suggested me to run
>> the "vacuum analyze" more frequently on this table.
>>
>> I had a setup a cronjob couple of weeks ago to run vacuum analyze
>> every 3 hours on this table and still my stats are totally wrong.
>> This is affecting the performance of the queries running on this
>> table very badly.
>> How can i fix this problem ?  or is this the standard postgres
>> behaviour ?
>>
>> Here are the stats from the problem table on my production database
>>
>> relpages |  reltuples
>> ----------+-------------
>>   168730 | 2.19598e+06
>>
>> If i rebuild the same table on dev db and check the stats they are
>> totally different, I was hoping that there would be some difference
>> in the stats from the production db stats but not at this extent, as
>> you can see below there is a huge difference in the stats.
>>
>> relpages | reltuples
>> ----------+-----------
>>    25230 |    341155
>>
>>
>> Thanks!
>> Pallav
>>
>
> What version of the database? As I recall, there are versions which
> suffer from index bloat if there is a large amount of turnover on the
> table. I believe VACUUM FULL ANALYZE helps with this. As does
> increasing the max_fsm_pages (after a vacuum full verbose the last
> couple of lines can give you an indication of how big max_fsm_pages
> might need to be.)
>
> Vacuum full does some locking, which means you don't want to do it all
> the time, but if you can do it on the weekend, or maybe evenings or
> something it might fix the problem.
>
> I don't know if you can recover without a vacuum full, but there might
> also be something about rebuild index, or maybe dropping and
> re-creating the index.
> John
> =:->

Hi John,

    Thanks! for the reply,  My postgres version is  7.4.2.  since this
is on a production database and one of critical table in our system I
cant run the vacuum full analyze on this table because of the locks. I
recently rebuilt this table from the scratch and recreated all the
indexes and after 2-3 weeks the same problem again. My max_fsm_pages are
set to the default value due think it might be the problem ? i would
like to change it but that involves restarting the postgres database
which i cant do at this moment . What is index bloat ?  do you think
rebuilding the indexes again might help some extent ?

Pallav