Re: First steps with 8.3 and autovacuum launcher

From: "Guillaume Smet" <guillaume(dot)smet(at)gmail(dot)com>
To: Decibel! <decibel(at)decibel(dot)org>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: First steps with 8.3 and autovacuum launcher
Date: 2007-09-22 10:06:57
Message-ID: 1d4e0c10709220306u13cc2edcy3ed465ec068d6c0c@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 9/19/07, Decibel! <decibel(at)decibel(dot)org> wrote:
> You missed my point... what we'd want to happen is for the analyze to
> take place while that table had a good chance of still being in memory.

It seems to be a bit too intrusive for 8.3 at this point.

> It might be worth looking into creating a different lock for ALTERs
> that actually change database page layout vs ALTERs that don't, since
> there's no reason you couldn't run ANALYZE while adding a PK (for
> example).

It seems to be a good idea.

As I restore a lot my test database (a real life 3.1 GB database) to
test the patches on like/ilike, here are some figures to show the
problem a bit more:

** 8.3 (autovacuum on as it's the default) **
Time taken by psql to load my SQL dump (the database is analyzed at
the end of the restore due to autovacuum launcher launching up to 3
processes in parallel):
real 52m55.398s
user 0m37.727s
sys 0m3.114s

** 8.2 (autovacuum off as it's the default) **
Time taken by psql to load the SQL dump:
real 15m5.032s
user 0m37.881s
sys 0m3.040s
Time to analyze the database:
cityvox=# \timing
Timing is on.
cityvox=# ANALYZE;
ANALYZE
Time: 45882.049 ms
So a total of: 16 minutes for 8.2 compared to 53 minutes for 8.3 to
have the database in the same state.

All settings except autovacuum are identical on both clusters.

--
Guillaume

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Guillaume Smet 2007-09-22 11:20:24 Re: like/ilike improvements
Previous Message Guillaume Smet 2007-09-22 08:37:22 Re: like/ilike improvements