Skip site navigation (1) Skip section navigation (2)

Re: Patch: Tie stats options to autovacuum in postgresql.conf

From: "Florian G(dot) Pflug" <fgp(at)phlo(dot)org>
To: "Jim C(dot) Nasby" <jim(at)nasby(dot)net>
Cc: David Wheeler <david(at)kineticode(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Patch: Tie stats options to autovacuum in postgresql.conf
Date: 2006-09-29 02:21:20
Message-ID: 451C8320.4080300@phlo.org (view raw or flat)
Thread:
Lists: pgsql-hackerspgsql-patches
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

In response to

pgsql-hackers by date

Next:From: Tom LaneDate: 2006-09-29 03:23:30
Subject: Re: New version of money type
Previous:From: Joshua D. DrakeDate: 2006-09-29 01:16:21
Subject: adminpack

pgsql-patches by date

Next:From: Markus SchaberDate: 2006-09-29 09:21:21
Subject: Re: Faster StrNCpy
Previous:From: Joshua D. DrakeDate: 2006-09-29 01:30:54
Subject: pgrowlocks(2)

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group