Received: from magus.postgresql.org (magus.postgresql.org [87.238.57.229]) by mail.postgresql.org (Postfix) with ESMTP id DC59819DE836 for ; Wed, 7 Mar 2012 12:53:02 -0400 (AST) Received: from mailsrv14.zmi.at ([212.69.164.54]) by magus.postgresql.org with esmtp (Exim 4.72) (envelope-from ) id 1S5K6f-0002iE-Fs for pgsql-admin@postgresql.org; Wed, 07 Mar 2012 16:53:01 +0000 Received: from mailsrv.i.zmi.at (h081217106014.dyn.cm.kabsi.at [81.217.106.14]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mailsrv2.i.zmi.at", Issuer "power4u.zmi.at" (not verified)) by mailsrv14.zmi.at (Postfix) with ESMTPSA id 6E8C11822430; Wed, 7 Mar 2012 17:52:10 +0100 (CET) Received: from saturn.localnet (saturn.i.zmi.at [10.72.27.2]) by mailsrv.i.zmi.at (Postfix) with ESMTP id 5CFC6CD7C8C; Wed, 7 Mar 2012 17:52:35 +0100 (CET) From: Michael Monnerie To: pgsql-admin@postgresql.org Cc: Kevin Grittner Subject: Re: speedup pg_dumpall Date: Wed, 07 Mar 2012 17:52 +0100 Message-ID: <2933170.uCZf1iJOXt@saturn> Organization: it-management http://it-management.at User-Agent: KMail/4.7.2 (Linux/3.1.9-1.4-desktop; KDE/4.7.2; x86_64; ; ) In-Reply-To: <4F461E2D0200002500045AC3@gw.wicourts.gov> References: <2829256.7Mb1lcLYlD@saturn> <4F461E2D0200002500045AC3@gw.wicourts.gov> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2536649.E3I573dqgm"; micalg="pgp-sha1"; protocol="application/pgp-signature" Content-Transfer-Encoding: quoted-printable X-Pg-Spam-Score: -2.6 (--) X-Archive-Number: 201203/25 X-Sequence-Number: 39213 --nextPart2536649.E3I573dqgm Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Am Donnerstag, 23. Februar 2012, 11:08:29 schrieb Kevin Grittner: > > What can I do to improve pg_dump performance? >=20 > =20 > I can't help wondering why you're running it. For routine backups > it is generally not your best option in PostgreSQL. PITR or warm > standby are generally more useful for routine backups of any > database big enough to worry about run time. =20 We're a hoster, so usually each database belongs to a different=20 customer. Each customer can have a "get a dump of our database daily"=20= dump. Also, restoring a single db is simpler when you got a dump of it.= > For my purposes, pg_dump is mostly useful for dumping schema as SQL > statements or dumping data from individual tables. Prior to the > availability of pg_upgrade our main use was for upgrades from one > major release to another, but I now see it as a pretty narrow niche > utility -- at least for my shop. Agreed, for a classical db server this could be better. We need the =20= per-db dumps, so pg_dump performance tuning would be nice. It's quite=20= slow currently. Someone got hints what to do against that? --=20 mit freundlichen Gr=C3=BCssen, Michael Monnerie, Ing. BSc it-management Internet Services: Prot=C3=A9ger http://proteger.at [gesprochen: Prot-e-schee] Tel: +43 660 / 415 6531 --nextPart2536649.E3I573dqgm Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (GNU/Linux) iEYEABECAAYFAk9XkjgACgkQzhSR9xwSCbQ96QCfYzpHSurj0tBdrVpEl9CeIibA RMkAoKmodE1a1cZy+w9vxmUrKxHlNWfK =YZMT -----END PGP SIGNATURE----- --nextPart2536649.E3I573dqgm--