Adrian Moisey wrote:
Hi
INFO: "blahxxx": scanned 27 of 27 pages, containing 1272 live rows
and 0 dead rows; 1272 rows in sample, 1272 estimated total rows
This is a small table that takes up 27 pages and it scanned all of
them. You have 1272 rows in it and none of them are dead (i.e.
deleted/updated but still taking up space).
I had a look through a few other tables...:
INFO: "table1": scanned 22988 of 22988 pages, containing 2713446 live
rows and 895662 dead rows; 45000 rows in sample, 2713446 estimate
d total rows
INFO: "table2": scanned 24600 of 24600 pages, containing 270585 live
rows and 65524 dead rows; 45000 rows in sample, 270585 estimated total rows
Is that dead rows an issue? Should I try clean it out? Will it improve
performance ?
What you're hoping to see is that figure remain stable. The point of the
free-space-map is to track these and allow the space to be re-used. If
you find that the number of dead rows is increasing then either you are:
1. Just deleting rows
2. Not vacuuming enough - check your autovacuum settings
The effect on performance is that when you read in a page from disk
you're reading dead rows along with the data you are after. Trying to
keep 0 dead rows in a constantly updated table isn't worth the effort
though - you'd end up wasting your disk I/O on maintenance rather than
queries.
The figures above look high to me - 90,000 out of 270,000 and 65,000 out
of 270,000. Of course, if these tables have just had bulk
updates/deletes then that's fine. If there's a steady stream of updates
though, you probably want to up your autovacuum settings.
--
Richard Huxton
Archonet Ltd
--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance
