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
---------------------------(end of broadcast)--------------------------- TIP 8: explain analyze is your friend
