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

Re: First steps with 8.3 and autovacuum launcher

From: Stefan Kaltenbrunner <stefan(at)kaltenbrunner(dot)cc>
To: Guillaume Smet <guillaume(dot)smet(at)gmail(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: First steps with 8.3 and autovacuum launcher
Date: 2007-10-01 15:44:02
Message-ID: 470115C2.7010403@kaltenbrunner.cc (view raw or flat)
Thread:
Lists: pgsql-hackers
Guillaume Smet wrote:
> On 9/22/07, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> Please try that experiment with all three configurations on both
>> versions:
>>         * autovacuum off
>>         * autovacuum on, autovacuum_vacuum_cost_delay = 0
>>         * autovacuum on, autovacuum_vacuum_cost_delay = 20
> 
> I've finally found some time to spend on these tests. Here are the results:
> 
> * 8.2.5 *
> - autovacuum off + ANALYZE: less than 16 minutes (figures previously
> posted in this thread) - default configuration of 8.2
> - autovacuum on, delay 0: 16m29
> - autovacuum on, delay 20: 16m13
> (I didn't repeat the run but we can see that autovacuum doesn't
> introduce too much slowdown during the restore operation)
> 
> * 8.3devel freshly compiled  *
> - autovacuum off: 14m39
> - autovacuum on, delay 0: 15m32
> - autovacuum on, delay 20: 51m37 (the box is idle during a large
> amount of this time) - default configuration of 8.3devel

some additional datapoints:

autovacuum on, delay 20: 8h 40min
autovacuum on, delay 0: 4h 23min

for restoring a database of around 120GB (on disk size) ...
In the delay 20 case the restore is more or less waiting hours for
grabbing locks during PK creation held by autovacuum (which tries to
analyze the tables).


Stefan

In response to

Responses

pgsql-hackers by date

Next:From: Michael GlaesemannDate: 2007-10-01 15:53:39
Subject: Re: IDE
Previous:From: Adrian MaierDate: 2007-10-01 15:27:57
Subject: Re: IDE

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