Received: from localhost (wm.hub.org [200.46.204.128])
	by postgresql.org (Postfix) with ESMTP id 45CF09FB34B
	for <pgsql-performance-postgresql.org@postgresql.org>;
	Wed, 27 Sep 2006 13:49:08 -0300 (ADT)
Received: from postgresql.org ([200.46.204.71])
	by localhost (mx1.hub.org [200.46.204.128]) (amavisd-new, port 10024)
	with ESMTP id 60838-03 for
	<pgsql-performance-postgresql.org@postgresql.org>;
	Wed, 27 Sep 2006 16:49:01 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-
Received: from www.axa.it (www.axa.it [194.242.232.5])
	by postgresql.org (Postfix) with ESMTP id 440D89FB334
	for <pgsql-performance@postgresql.org>;
	Wed, 27 Sep 2006 13:49:01 -0300 (ADT)
Received: from localhost (localhost.localdomain [127.0.0.1])
	by localhost.axa.it (Postfix) with ESMTP id 5F18EA50442
	for <pgsql-performance@postgresql.org>;
	Wed, 27 Sep 2006 18:49:00 +0200 (CEST)
Received: from www.axa.it ([127.0.0.1])
	by localhost (www.axa.it [127.0.0.1]) (amavisd-new,
	port 10024) with LMTP
	id 12183-03-20 for <pgsql-performance@postgresql.org>;
	Wed, 27 Sep 2006 18:48:59 +0200 (CEST)
Received: from [192.168.0.71] (adsl-ull-84-199.48-151.net24.it
 [151.48.199.84])
	by www.axa.it (Postfix) with ESMTP id 63CEAA5043E
	for <pgsql-performance@postgresql.org>;
	Wed, 27 Sep 2006 18:48:59 +0200 (CEST)
Message-ID: <451AAB93.6010602@axa.it>
Date: Wed, 27 Sep 2006 18:49:23 +0200
From: Edoardo Ceccarelli <eddy@axa.it>
User-Agent: Thunderbird 1.5.0.7 (Windows/20060909)
MIME-Version: 1.0
Cc: pgsql-performance@postgresql.org
Subject: Re: autovacuum on a -mostly- r/o table
References: <451AA1FE.9050704@axa.it> <1159374712.46586.47.camel@home>
In-Reply-To: <1159374712.46586.47.camel@home>
Content-Type: multipart/alternative;
	boundary="------------040004090202070400030203"
X-Virus-Scanned: amavisd-new at axa.it
X-Virus-Scanned: Maia Mailguard 1.0.1
X-Spam-Status: No, hits=0.375 tagged_above=0 required=5 tests=HTML_30_40,
	HTML_MESSAGE
X-Spam-Level: 
X-Archive-Number: 200609/364
X-Sequence-Number: 21050

This is a multi-part message in MIME format.
--------------040004090202070400030203
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Rod Taylor wrote:
> On Wed, 2006-09-27 at 18:08 +0200, Edoardo Ceccarelli wrote:
>   
>> I have read that autovacuum cannot check to see pg load before
>> launching 
>> vacuum but is there any patch about it? that would sort out the
>> problem 
>> in a good and simple way. 
>>     
>
> In some cases the solution to high load is to vacuum the tables being
> hit the heaviest -- meaning that simply checking machine load isn't
> enough to make that decision.
>
> In fact, that high load problem is exactly why autovacuum was created in
> the first place.
>   
True,
but autovacuum could check load -before- and -during- it's execution and 
it could adjust himself automatically to perform more or less 
aggressively depending on the difference between those two values.
Maybe with a parameter like: maximum-autovacuum-load=0.2
that would mean: "never load the machine more than 20% for the autovacuum"

...another thing is, how could autovacuum check for machine load, this 
is something I cannot imagine right now...


--------------040004090202070400030203
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Rod Taylor wrote:
<blockquote cite="mid1159374712.46586.47.camel@home" type="cite">
  <pre wrap="">On Wed, 2006-09-27 at 18:08 +0200, Edoardo Ceccarelli wrote:
  </pre>
  <blockquote type="cite">
    <pre wrap="">I have read that autovacuum cannot check to see pg load before
launching 
vacuum but is there any patch about it? that would sort out the
problem 
in a good and simple way. 
    </pre>
  </blockquote>
  <pre wrap=""><!---->
In some cases the solution to high load is to vacuum the tables being
hit the heaviest -- meaning that simply checking machine load isn't
enough to make that decision.

In fact, that high load problem is exactly why autovacuum was created in
the first place.
  </pre>
</blockquote>
True, <br>
but autovacuum could check load -before- and -during- it's execution
and it could adjust himself automatically to perform more or less
aggressively depending on the difference between those two values.<br>
Maybe with a parameter like: maximum-autovacuum-load=0.2<br>
that would mean: "never load the machine more than 20% for the
autovacuum"<br>
<br>
...another thing is, how could autovacuum check for machine load, this
is something I cannot imagine right now...<br>
<br>
</body>
</html>

--------------040004090202070400030203--