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
Views: Raw Message | Whole Thread | Download mbox | Resend email
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

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Glaesemann 2007-10-01 15:53:39 Re: IDE
Previous Message Adrian Maier 2007-10-01 15:27:57 Re: IDE