This is a multi-part message in MIME format.
------_=_NextPart_001_01C89D01.C91D02AF
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
We're having what seem like serious performance issues with pg_dump, and =
I hope someone can help. =20
We have several tables that are used to store binary data as bytea (in =
this example image files), but we're having similar time issues with =
text tables as well.
In my most recent test, the sample table was about 5 GB in 1644 rows, =
with image files sizes between 1 MB and 35 MB. The server was a 3.0 GHz =
P4 running WinXP, with 2 GB of ram, the backup stored to a separate disk =
from the data, and little else running on the sytem.
We're doing the following:
=20
pg_dump -i -h localhost -p 5432 -U postgres -F c -v -f =
"backupTest.backup" -t "public"."images" db_name
In the test above, this took 1hr 45min to complete. Since we expect to =
have users with 50-100GB of data, if not more, backup times that take =
nearly an entire day are unacceptable.
We think there must be something we're doing wrong. A search turned up a =
similar thread =
(http://archives.postgresql.org/pgsql-performance/2007-12/msg00404.php),
=
but our number are so much higher than those that we must be doing =
something very wrong. Hopefully, either there's a server setting or =
pg_dump option we need to change, but we're open to design changes if =
necessary.
Can anyone who has dealt with this before advise us?
Thanks!
Ryan
=20
------_=_NextPart_001_01C89D01.C91D02AF
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
6.5.7652.24">
<TITLE>Slow pg_dump</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/plain format -->
<BR>
<P><FONT SIZE=3D2>We're having what seem like serious performance issues =
with pg_dump, and I hope someone can help. <BR>
<BR>
We have several tables that are used to store binary data as bytea (in =
this example image files), but we're having similar time issues with =
text tables as well.<BR>
<BR>
In my most recent test, the sample table was about 5 GB in 1644 rows, =
with image files sizes between 1 MB and 35 MB. The server was a =
3.0 GHz P4 running WinXP, with 2 GB of ram, the backup stored to a =
separate disk from the data, and little else running on the sytem.<BR>
<BR>
We're doing the following:<BR>
<BR>
pg_dump -i -h localhost -p 5432 -U postgres -F c -v -f =
"backupTest.backup" -t "public"."images" =
db_name<BR>
<BR>
In the test above, this took 1hr 45min to complete. Since we =
expect to have users with 50-100GB of data, if not more, backup times =
that take nearly an entire day are unacceptable.<BR>
<BR>
We think there must be something we're doing wrong. A search turned up a =
similar thread (<A =
HREF=3D"http://archives.postgresql.org/pgsql-performance/2007-12/msg00404=
..php">http://archives.postgresql.org/pgsql-performance/2007-12/msg00404.p=
hp</A>), but our number are so much higher than those that we must be =
doing something very wrong. Hopefully, either there's a server =
setting or pg_dump option we need to change, but we're open to design =
changes if necessary.<BR>
<BR>
Can anyone who has dealt with this before advise us?<BR>
<BR>
Thanks!<BR>
Ryan<BR>
<BR>
<BR>
<BR>
<BR>
<BR>
<BR>
</FONT>
</P>
</BODY>
</HTML>
------_=_NextPart_001_01C89D01.C91D02AF--
|
