Yes I can create a simpler version that exhibits the problem:
postgres_bug_simpler.sql
<http://postgresql.1045698.n5.nabble.com/file/n5806320/postgres_bug_simpler.sql>
This only now involves one smaller table 60K rows, and a linked table with
20M rows. I tried with 6K and 1M but could not get problem to occur. Both
are now unchanging in size. The smaller table gets updated frequently, and
then starts exhibiting the bad query plan, it seems especially after the 2nd
auto vacuum and auto analyze. When the dead_rows goes to zero in the stats
the live_tup can stay at an huge factor larger than the table really is for
some time.
In my system the smaller table that is updated frequently grows only
slightly if at all. I never want a table scan to happen of the big table,
but even with enable_seq_scan=false set in functions that query these tables
I can get the bad query plan.
Would it be possible to have a setting on a table that gave an expression
for determining the table size? IE For key highly updated tables I could set
and maintain the meta-data for the size table and even shape of the data.
Then for these tables autovac would not need to make the effort of having to
estimate size.
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-tp5804416p5806320.html
Sent from the PostgreSQL - performance mailing list archive at Nabble.com.
