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! Thanks!
(It
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 -d
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 test
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 (
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
