Skip site navigation (1) Skip section navigation (2)

Re: Wrong Stats and Poor Performance

From: John A Meinel <john(at)arbash-meinel(dot)com>
To: Pallav Kalva <pkalva(at)deg(dot)cc>
Cc: pgsql-performance(at)postgresql(dot)org
Subject: Re: Wrong Stats and Poor Performance
Date: 2004-12-27 19:27:31
Message-ID: 41D06223.9060500@arbash-meinel.com (view raw or flat)
Thread:
Lists: pgsql-performance
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
=:->

In response to

Responses

pgsql-performance by date

Next:From: Pallav KalvaDate: 2004-12-27 19:51:21
Subject: Re: Wrong Stats and Poor Performance
Previous:From: Pallav KalvaDate: 2004-12-27 18:52:27
Subject: Wrong Stats and Poor Performance

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group