Re: db size

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