"jimbob@seagate.com" <jimbob@seagate.com> wrote:=0A=0A> INFO:=A0 analyzing =
"public.stream_file"=0A> INFO:=A0 "stream_file": scanned 30000 of 2123642 p=
ages, containing=0A> 184517 live rows and 2115512 dead rows; 30000 rows in =
sample,=0A> 158702435 estimated total rows=0A=0A184517 live rows in 30000 r=
andomly sampled pages out of 2123642=0Atotal pages, means that the statisti=
cs predict that a select=0Acount(*) will find about=A0 13 million live rows=
to count.=0A=0A> After "analyze verbose", the table shows 158 million rows=
. A=0A> select count(1) yields 13.8 million rows.=0A=0AOK, the estimate was=
13 million and there were actually 13.8=0Amillion, but it is a random samp=
le used to generate estimates. =0AThat seems worse than average, but close =
enough to be useful.=0AThe 158.7 million total rows includes dead rows, whi=
ch must be=0Avisited to determine visibility, but will not be counted becau=
se=0Athey are not visible to the counting transaction.=A0 Having over 90%=
=0Aof your table filled with dead rows is a bad situation to be in,=0Afrom =
a performance standpoint.=A0 You should use aggressive=0Amaintenance (like =
VACUUM FULL or CLUSTER) to fix the existing=0Aextreme bloat, and then revie=
w your autovacuum settings and overall=0Avacuum regimen to prevent future b=
loat.=0A=0AThis does not look like a bug from the information provided so f=
ar.=0A=0A-Kevin