From: Galy Lee <lee.galy@oss.ntt.co.jp>
To: pgsql-hackers@postgresql.org
Cc: jim@nasby.net
Subject: Re: [PERFORM] how to plan for vacuum?
Date: Thu, 25 Jan 2007 19:52:50 +0900
Message-ID: <45B88C02.3010802@oss.ntt.co.jp> (raw)
In-Reply-To: <20070125035741.GE64372@nasby.net>
References: <45B6F0A8.1050705@oss.ntt.co.jp>
<20070125033917.GD64372@nasby.net>
<20070125035202.GI26006@alvh.no-ip.org>
<20070125035741.GE64372@nasby.net>
Jim C. Nasby wrote:
> On Thu, Jan 25, 2007 at 12:52:02AM -0300, Alvaro Herrera wrote:
>> Jim C. Nasby wrote:
>>
>>> I'll generally start with a cost delay of 20ms and adjust based on IO
>>> utilization.
>> I've been considering set a default autovacuum cost delay to 10ms; does
>> this sound reasonable?
The problem in here is that we can not easily find a direct relation
between
Cost delay <-> CPU/IO utilization <--> real performance (response
time in peak hour)
It is very hard for any normal user to set this correctly. I think the
experience / trial-and-error approach is awful for the user, every DBA
need to be an expert of vacuum to keep the system stable. For vacuum is
still a big threat to the performance, a more intelligent way is needed.
A lot of efforts have contributed to make vacuum to be a more
lightweight operation, but I think we should still need more efforts on
how to make it can be used easily and safely.
So I have proposed the "vacuum in time" feature in previous; just let
vacuum know how long can it runs, and then it will minimize the impact
in the time span for you. Some argue that it should not have the
maintenance window assumption, but the most safely way is to run in the
maintenance window.
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-performance@postgresql.org
Cc: lee.galy@oss.ntt.co.jp, pgsql-hackers@postgresql.org, jim@nasby.net
Subject: Re: [PERFORM] how to plan for vacuum?
In-Reply-To: <45B88C02.3010802@oss.ntt.co.jp>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox