Re: pg 8.3beta 2 restore db with autovacuum report - Mailing list pgsql-hackers

From Alvaro Herrera
Subject Re: pg 8.3beta 2 restore db with autovacuum report
Date
Msg-id 20071102205527.GG2374@alvh.no-ip.org
Whole thread Raw
In response to pg 8.3beta 2 restore db with autovacuum report  (andy <andy@squeakycode.net>)
Responses Re: pg 8.3beta 2 restore db with autovacuum report  ("Guillaume Smet" <guillaume.smet@gmail.com>)
Re: pg 8.3beta 2 restore db with autovacuum report  (andy <andy@squeakycode.net>)
List pgsql-hackers
andy wrote:
>
> with autovacuum enabled with default settings, cramd.sql is 154M:
>
> andy@slacker:/pub/back$ time pg_restore -Fc -C -d postgres cramd.sql
>
> real    3m43.687s

[...]

> Now I dropdb and disable autovacuum, restart pg:
>
> andy@slacker:/pub/back$ time ( pg_restore -Fc -C -d postgres cramd.sql; 
> vacuumdb -z cramd )
>
> real    3m47.229s
> user    0m9.933s
> sys     0m0.744s
>
> Sweet, about the same amount of time.

Thanks.  I find it strange that it takes 3 minutes to restore a 150 MB
database ... do you have many indexes?

Even though the restore times are very similar, I find it a bit
disturbing that the "CREATE INDEX" is shown to be waiting.  Was it just
bad luck that the ps output shows it that way, or does it really wait
for long?

-- 
Alvaro Herrera                                http://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support


pgsql-hackers by date:

Previous
From: "Joshua D. Drake"
Date:
Subject: Re: Machine available for community use
Next
From: Alvaro Herrera
Date:
Subject: Re: [GENERAL] AutoVacuum Behaviour Question