Re: BUG #7853: Incorrect statistics in table with many dead rows.

"jimbob(at)seagate(dot)com" <jimbob(at)seagate(dot)com> wrote:

> INFO:  analyzing "public.stream_file"
> INFO:  "stream_file": scanned 30000 of 2123642 pages, containing
> 184517 live rows and 2115512 dead rows; 30000 rows in sample,
> 158702435 estimated total rows

184517 live rows in 30000 randomly sampled pages out of 2123642
total pages, means that the statistics predict that a select
count(*) will find about  13 million live rows to count.

> After "analyze verbose", the table shows 158 million rows. A
> select count(1) yields 13.8 million rows.

OK, the estimate was 13 million and there were actually 13.8
million, but it is a random sample used to generate estimates.
That seems worse than average, but close enough to be useful.
The 158.7 million total rows includes dead rows, which must be
visited to determine visibility, but will not be counted because
they are not visible to the counting transaction.  Having over 90%
of your table filled with dead rows is a bad situation to be in,
from a performance standpoint.  You should use aggressive
maintenance (like VACUUM FULL or CLUSTER) to fix the existing
extreme bloat, and then review your autovacuum settings and overall
vacuum regimen to prevent future bloat.

This does not look like a bug from the information provided so far.

-Kevin