Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtp (Exim 4.72) (envelope-from ) id 1TMR3V-00067Z-1F for pgsql-performance@postgresql.org; Thu, 11 Oct 2012 22:16:37 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by magus.postgresql.org with esmtp (Exim 4.72) (envelope-from ) id 1TMR3T-0007jM-Df for pgsql-performance@postgresql.org; Thu, 11 Oct 2012 22:16:36 +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 q9BMGXQ6001270; Thu, 11 Oct 2012 18:16:33 -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: <16863.1348151708@sss.pgh.pa.us> Comments: In-reply-to Sergio Gabriel Rodriguez message dated "Thu, 11 Oct 2012 18:46:04 -0300" Date: Thu, 11 Oct 2012 18:16:33 -0400 Message-ID: <1269.1349993793@sss.pgh.pa.us> X-Pg-Spam-Score: -4.0 (----) X-Archive-Number: 201210/154 X-Sequence-Number: 48113 Sergio Gabriel Rodriguez writes: > I tried with Postgresql 9.2 and the process used to take almost a day > and a half, was significantly reduced to 6 hours, before failing even used > to take four hours. My question now is, how long should it take the backup > for a 200GB database with 80% of large objects? It's pretty hard to say without knowing a lot more info about your system than you provided. One thing that would shed some light is if you spent some time finding out where the time is going --- is the system constantly I/O busy, or is it CPU-bound, and if so in which process, pg_dump or the connected backend? Also, how many large objects is that? (If you don't know already, "select count(*) from pg_largeobject_metadata" would tell you.) regards, tom lane