Jim C. Nasby wrote:
On Thu, Sep 28, 2006 at 03:07:39PM -0700, David Wheeler wrote:
PostgreSQLers,
I just ran into an issue where a client thought that autovacuum was
running but it wasn't. This is because it's not fatal when autovacuum
is on but stats_start_collector and/or stats_row_level is off. I
suspect that there's a reason that it's not fatal, so I thought that
it might be useful to give folks just a little bit of help by telling
them in postgresql.conf that they need to enable them in order for
autovacuum to work.
+1. I was just at a client today that had run into this problem.
Actually, I'm in favor of refusing to start if autovac is on but the
proper stats settings aren't. I'd rather that then people ending up with
bloated databases and crappy performance.
If think that setting autovacuum to on should even force
stats_collector and stats_row_level to on - together with a warning if
they would otherwise be off.
The risk of autovacuum being disabled by accident seems to risk a much
worse performance penatly then having the statistics collector running
by accident. Additionally, the statistics collector can easily be turned
off within seconds even _if_ it was on accidentally, but if vacuuming was
disabled by accident, the user might have to run "vacuum full" - with all
the concurrency issues that this implies..
greetings, Florian flug
---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
