I have now created a repeatable test for this ...bug, well that may be
debatable, but getting the query plan this wrong after vacum and analyze
have run certainly looks like a bug to me.
I have created a test case that matches my problem domain but can probably
be simplified.
postgres_bug.sql
<http://postgresql.1045698.n5.nabble.com/file/n5806302/postgres_bug.sql>
Even after autovac vacuum and autovac analyze have run the query plan goes
from using indexes on the big table to table scanning them as it thinks my
unit_test table is large due to the error in the estimate for rows in the
table that autovac generated. Once you run a cluster on the table all goes
back to using the correct indexes. And the next autovacuum gets things
straight again on the stats table.
Look forward to solution as this is hurting us. A very hot table on our
system goes bad every night and needs constant watching.
regards
Tim
--
View this message in context:
http://postgresql.1045698.n5.nabble.com/autovacuum-vacuum-creates-bad-statistics-for-planner-when-it-log-index-scans-0-tp5804416p5806302.html
Sent from the PostgreSQL - performance mailing list archive at Nabble.com.
