From: | "Todd A(dot) Cook" <tcook(at)blackducksoftware(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Ruairi <rcarroll(at)bluemetrix(dot)com>, pgsql-admin(at)postgresql(dot)org |
Subject: | Re: Restore of pg_dump taking a long time... |
Date: | 2006-05-24 19:42:25 |
Message-ID: | 4474B721.8040101@blackducksoftware.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-admin |
Tom Lane wrote:
>
> There's not much you can do to improve the performance of a restore
> already in progress. Next time you might want to think about kicking up
> maintenance_work_mem before you start it; that's about the only thing
> you can really do to speed up index builds.
I have found that increasing maintenance_work_mem can decrease index
build speed on large tables:
maintenance_work_mem 32768 262144 1048576 2097151
---------------------------------------------------------------
index 400M rows (min) 55 61 68 70
index 45M rows (min) 4.03 4.22 4.88 2.55
These timings were done on a machine with 8GB ram and postgresql 8.1.3
(from the RPMs on postgresql.org) Each time is an average of three
runs; before each run, postgres was shut down and the filesystem with
/var/lib/pgsql was remounted to clear the filesystem cache.
I'm assuming that the times are increasing because there is less
memory available for the filesystem cache. Similarly, I assume that
the runs on the smaller table with maintenance_work_mem = 2097151
are faster because everything fits in that space.
-- todd
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2006-05-24 19:48:38 | Re: Restore of pg_dump taking a long time... |
Previous Message | Scott Marlowe | 2006-05-24 19:00:10 | Re: Restore of pg_dump taking a long time... |