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

Re: pgsql-server: Vacuum delay activated by default.

From: "Marc G(dot) Fournier" <scrappy(at)postgresql(dot)org>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Jan Wieck <JanWieck(at)Yahoo(dot)com>, pgsql-committers(at)postgresql(dot)org
Subject: Re: pgsql-server: Vacuum delay activated by default.
Date: 2004-08-07 17:27:02
Message-ID: 20040807142525.H1212@ganymede.hub.org (view raw or flat)
Thread:
Lists: pgsql-committers
On Sat, 7 Aug 2004, Tom Lane wrote:

> Jan Wieck <JanWieck(at)Yahoo(dot)com> writes:
>> On 8/7/2004 12:47 AM, Tom Lane wrote:
>>> What?  If there was consensus to do this, I missed it.  If there was
>>> even any *discussion* of doing this, I missed it.
>
>> How many questions about vacuum still grabbing all available bandwidth,
>> vacuum slowing down the whole system, vacuum being all evil do you want
>> to answer for 8.0? Over and over again we are defending reasonable
>> default configuration values against gazillions of little switches, and
>> this is a reasonable default that will be a relief for large databases
>> and makes more or less no difference for small ones.
>
> What basis do you have for saying that this is a reasonable default?
> Does anyone else agree?

Just curious, but isn't this one of the key points about pg_autovacuum in 
the first place?  So that you vacuum what needs to be vacuum'd, and not 
*everything* ... ?  Shouldn't the answer to the 'bandwidth issue' change 
to 'you should install/use pg_autovacuum'?

----
Marc G. Fournier           Hub.Org Networking Services (http://www.hub.org)
Email: scrappy(at)hub(dot)org           Yahoo!: yscrappy              ICQ: 7615664

In response to

Responses

pgsql-committers by date

Next:From: Tom LaneDate: 2004-08-07 17:40:49
Subject: pgsql-server: Don't try to rewrite NEW references in a utility statement
Previous:From: Tom LaneDate: 2004-08-07 16:45:58
Subject: Re: pgsql-server: Vacuum delay activated by default.

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