Guillaume Smet wrote:
> I did the test again with the reference database I used a month ago.
>
> My previous figures with 8.3devel of October 1st were:
> - autovacuum off: 14m39
> - autovacuum on, delay 20: 51m37
>
> With 8.3devel of today, I have:
> - autovacuum on, delay 20: 15m26
Yay! Thank
Alvaro Herrera wrote:
andy wrote:
with autovacuum enabled with default settings, cramd.sql is 154M:
[EMAIL PROTECTED]:/pub/back$ time pg_restore -Fc -C -d postgres cramd.sql
real3m43.687s
[...]
Now I dropdb and disable autovacuum, restart pg:
[EMAIL PROTECTED]:/pub/back$ time ( pg_res
Alvaro,
On 11/2/07, Alvaro Herrera <[EMAIL PROTECTED]> wrote:
> 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?
I did the t
andy wrote:
>
> with autovacuum enabled with default settings, cramd.sql is 154M:
>
> [EMAIL PROTECTED]:/pub/back$ time pg_restore -Fc -C -d postgres cramd.sql
>
> real3m43.687s
[...]
> Now I dropdb and disable autovacuum, restart pg:
>
> [EMAIL PROTECTED]:/pub/back$ time ( pg_restore -Fc -C
with autovacuum enabled with default settings, cramd.sql is 154M:
[EMAIL PROTECTED]:/pub/back$ time pg_restore -Fc -C -d postgres cramd.sql
real3m43.687s
user0m11.689s
sys 0m0.868s
[EMAIL PROTECTED]:/pub/back$
during restore we see scary things like:
[EMAIL PROTECTED]:~# ps awx|gr
