| From: | Patrick Hatcher <PHatcher(at)macys(dot)com> |
|---|---|
| To: | pgsql-general(at)postgresql(dot)org |
| Cc: | Aron Bartling <abartling(at)macys(dot)com> |
| Subject: | Slow pgdump |
| Date: | 2005-11-23 01:13:44 |
| Message-ID: | OF60486770.8EC48273-ON882570C2.0004E59F-882570C2.0006BE3D@FDS.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
OS - RH3
Pg - 7.4.9
Ram - 8G
Disk-709G Raid 0+1
We are having a pgdump issue that we can't seem to find an answer for
Background:
Production server contains 11 databases of which 1 database comprises 85%
of the 194G used on the drive. This one large db contains 12 schemas.
Within the schemas of the large db, there maybe 1 or 2 views that span
across 2 schemas.
If we do a backup using pgdump against the entire database, it will take
upwards of 8+ hours for the backup to complete.
If we split the backup up to do a pgdump for the first 10 dbs and then do a
pgdump by schema on the 1 large db, the the backup takes only 3.5hrs
The other than using the schema switch, there is no compression happening
on either dump.
Any ideas why this might be happening or where we can check for issues?
TIA
Patrick Hatcher
Development Manager Analytics/MIO
Macys.com
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Joe Conway | 2005-11-23 04:42:08 | Re: Set Returning Function (Pipelining) |
| Previous Message | Thomas F. O'Connell | 2005-11-22 21:47:17 | Index Administration: pg_index vs. pg_get_indexdef() |