Derrick Rice <derrick.rice@xxxxxxxxx> wrote: > I recently ran into a problem with a planner opting for a > sequential scan rather than a bitmap heap scan because the stats > suggested that my delete query was going to affect 33% of the > rows, rather than the 1% it really was. > could possibly react by updating the histogram_bounds at > commit-time, rather than needing an additional analyze or needing > auto-analyze settings jacked way up. I recommend you try version 9.0 with default autovacuum settings and see how things go. If you still have an issue, let's talk then. Besides numerous autovacuum improvements, which make it more reliable and less likely to noticeably affect runtime of your queries, there is a feature to probe the end of an index's range in situations where data skew was often causing less than optimal plans to be chosen. >From what you've told us, I suspect you won't see this problem in 9.0 unless you shoot yourself in the foot by crippling autovacuum. -Kevin -- Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
