[HACKERS] Patch: Tie stats options to autovacuum in postgresql.conf
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. If this patch is not correctly formatted or against the proper file, please let me know and I'll make the necessary modifications. Thanks, David vacuam_stats.patch Description: Binary data ---(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
Re: [HACKERS] Patch: Tie stats options to autovacuum in postgresql.conf
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. -- Jim Nasby[EMAIL PROTECTED] EnterpriseDB http://enterprisedb.com 512.569.9461 (cell) ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] Patch: Tie stats options to autovacuum in postgresql.conf
On Sep 28, 2006, at 16:39, Jim C. Nasby wrote: +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. I agree, but I figured that this was a start, at least. Best, David ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] Patch: Tie stats options to autovacuum in postgresql.conf
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
