Received: from makus.postgresql.org ([98.129.198.125]) by malur.postgresql.org with esmtp (Exim 4.72) (envelope-from ) id 1TEhre-0003FU-SH for pgsql-performance@postgresql.org; Thu, 20 Sep 2012 14:36:27 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by makus.postgresql.org with esmtp (Exim 4.72) (envelope-from ) id 1TEhrd-0005Xv-3a for pgsql-performance@postgresql.org; Thu, 20 Sep 2012 14:36:26 +0000 Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1]) by sss.pgh.pa.us (8.14.5/8.14.5) with ESMTP id q8KEZ8LS016864; Thu, 20 Sep 2012 10:35:08 -0400 (EDT) From: Tom Lane To: Sergio Gabriel Rodriguez cc: pgsql-performance@postgresql.org Subject: Re: problems with large objects dump In-reply-to: References: Comments: In-reply-to Sergio Gabriel Rodriguez message dated "Thu, 20 Sep 2012 09:06:35 -0300" Date: Thu, 20 Sep 2012 10:35:08 -0400 Message-ID: <16863.1348151708@sss.pgh.pa.us> X-Pg-Spam-Score: -2.4 (--) X-Archive-Number: 201209/88 X-Sequence-Number: 47834 Sergio Gabriel Rodriguez writes: > Our production database, postgres 8.4 has an approximate size of 200 GB, > most of the data are large objects (174 GB), until a few months ago we used > pg_dump to perform backups, took about 3-4 hours to perform all the > process. Some time ago the process became interminable, take one or two > days to process, we noticed that the decay process considerably to startup > backup of large object, so we had to opt for physical backups. Hm ... there's been some recent work to reduce O(N^2) behaviors in pg_dump when there are many objects to dump, but I'm not sure that's relevant to your situation, because before 9.0 pg_dump didn't treat blobs as full-fledged database objects. You wouldn't happen to be trying to use a 9.0 or later pg_dump would you? Exactly what 8.4.x release is this, anyway? regards, tom lane