From: | Greg Smith <gsmith(at)gregsmith(dot)com> |
---|---|
To: | Pascal Cohen <pcohen(at)wimba(dot)com> |
Cc: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: Improve dump and restore time |
Date: | 2008-10-13 10:49:12 |
Message-ID: | Pine.GSO.4.64.0810130643190.3332@westnet.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On Fri, 10 Oct 2008, Pascal Cohen wrote:
> Are there best practices to reduce the migration time ?
There's a number of resources in this area listed at
http://wiki.postgresql.org/wiki/Bulk_Loading_and_Restores
> I wanted to have an expectation of the migration duration and performed it on
> a less powerful machine than the one we have in Production.
Note that if your production server has any sort of decent disk controller
in it, but the test machine doesn't, you can end up with results that
don't extrapolate very well. That's particularly true if you don't follow
the standard good practice on the restore (like using the default value
for checkpoint_segments). As mentioned in the above, using syncronous
commit can help a lot there on some systems.
If you do any restore tests again, try and look at what the bottleneck is
on the system using something like vmstat, and make sure you check the
database log files (that will tell you if the checkpoint stuff is setup
reasonably or not). It's really hard to say whether any of the things you
were asking about will be helpful or not without knowing what the limiting
factor on your system is. If you're CPU limited for example, you'd want
to stay away from compression; if I/O limited that might make sense.
--
* Greg Smith gsmith(at)gregsmith(dot)com http://www.gregsmith.com Baltimore, MD
From | Date | Subject | |
---|---|---|---|
Next Message | Pavel Stehule | 2008-10-13 11:04:40 | Re: PL/pgSQL stored procedure returning multiple result sets (SELECTs)? |
Previous Message | Gregory Stark | 2008-10-13 10:44:54 | Re: Out of memory in create index |