pg_dump and pg_restore - Mailing list pgsql-performance

From Jayadevan M
Subject pg_dump and pg_restore
Date
Msg-id OF39355A75.04FF8085-ON65257726.0013F803-65257726.001BE662@ibsplc.com
Whole thread Raw
In response to Re: old server, new server, same performance  ("Kevin Grittner" <Kevin.Grittner@wicourts.gov>)
Responses Re: pg_dump and pg_restore  (Robert Haas <robertmhaas@gmail.com>)
Re: pg_dump and pg_restore  (Peter Koczan <pjkoczan@gmail.com>)
List pgsql-performance
Hello all,
I was testing how much time a pg_dump backup would take to get restored. Initially, I tried it with psql (on a backup taken with pg_dumpall). It took me about one hour. I felt that I should target for a recovery time of 15 minutes to half an hour. So I went through the blogs/documentation etc and switched to pg_dump and pg_restore. I tested only the database with the maximum volume of data (about 1.5 GB). With
pg_restore -U postgres -v -d PROFICIENT --clean -Fc proficient.dmp
it took about 45 minutes. I tried it with
pg_restore -U postgres -j8 -v -d PROFICIENT --clean -Fc proficient.dmp
Not much improvement there either. Have I missed something or 1.5 GB data on a machine with the following configuration will take about 45 minutes? There is nothing else running on the machine consuming memory or CPU. Out of 300 odd tables, about 10 tables have millions of records, rest are all having a few thousand records at most.

Here are the specs  ( a pc class  machine)-

PostgreSQL 8.4.3 on i686-pc-linux-gnu
CentOS release 5.2
Intel(R) Pentium(R) D CPU 2.80GHz
2 GB RAM
Storage is local disk.

Postgresql parameters (what I felt are relevant) -
max_connections = 100
shared_buffers = 64MB
work_mem = 16MB
maintenance_work_mem = 16MB
synchronous_commit on


Thank you for any suggestions.
Jayadevan





DISCLAIMER:


"The information in this e-mail and any attachment is intended only for the person to whom it is addressed and may contain confidential and/or privileged material. If you have received this e-mail in error, kindly contact the sender and destroy all copies of the original communication. IBS makes no warranty, express or implied, nor guarantees the accuracy, adequacy or completeness of the information contained in this email or any attachment and is not liable for any errors, defects, omissions, viruses or for resultant loss or damage, if any, direct or indirect."





pgsql-performance by date:

Previous
From: Robert Haas
Date:
Subject: Re: Planner issue on sorting joining of two tables with limit
Next
From: Віталій Тимчишин
Date:
Subject: Re: Benchmark with FreeBSD 8.0 and pgbench