Received: from makus.postgresql.org (makus.postgresql.org [98.129.198.125]) by mail.postgresql.org (Postfix) with ESMTP id B015911DF226; Thu, 31 May 2012 11:51:36 -0300 (ADT) Received: from sss.pgh.pa.us ([66.207.139.130]) by makus.postgresql.org with esmtp (Exim 4.72) (envelope-from ) id 1Sa6it-0008CG-SI; Thu, 31 May 2012 14:51:36 +0000 Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1]) by sss.pgh.pa.us (8.14.2/8.14.2) with ESMTP id q4VEop2e010444; Thu, 31 May 2012 10:50:51 -0400 (EDT) To: Robert Haas cc: Claudio Freire , Robert Klemme , Tatsuo Ishii , pgsql-performance@postgresql.org, pgsql-hackers@postgresql.org Subject: Re: [HACKERS] pg_dump and thousands of schemas In-reply-to: References: <20120529.185149.1127748531209576379.t-ishii@sraoss.co.jp> <20120531.174526.2183902405630094684.t-ishii@sraoss.co.jp> <20120531.230757.2014494683420217075.t-ishii@sraoss.co.jp> <9787.1338474676@sss.pgh.pa.us> Comments: In-reply-to Robert Haas message dated "Thu, 31 May 2012 10:41:17 -0400" Date: Thu, 31 May 2012 10:50:51 -0400 Message-ID: <10443.1338475851@sss.pgh.pa.us> From: Tom Lane X-Pg-Spam-Score: -1.9 (-) X-Archive-Number: 201205/189 X-Sequence-Number: 47013 Robert Haas writes: > On Thu, May 31, 2012 at 10:31 AM, Tom Lane wrote: >> I'm not; Jeff Janes is.  But you shouldn't be holding your breath >> anyway, since it's 9.3 material at this point. > I agree we can't back-patch that change, but then I think we ought to > consider back-patching some variant of Tatsuo's patch. Maybe it's not > reasonable to thunk an arbitrary number of relation names in there on > one line, but how about 1000 relations per LOCK statement or so? I > guess we'd need to see how much that erodes the benefit, but we've > certainly done back-branch rearrangements in pg_dump in the past to > fix various kinds of issues, and this is pretty non-invasive. I am not convinced either that this patch will still be useful after Jeff's fix goes in, or that it provides any meaningful savings when you consider a complete pg_dump run. Yeah, it will make the lock acquisition phase faster, but that's not a big part of the runtime except in very limited scenarios (--schema-only, perhaps). The performance patches we applied to pg_dump over the past couple weeks were meant to relieve pain in situations where the big server-side lossage wasn't the dominant factor in runtime (ie, partial dumps). But this one is targeting exactly that area, which is why it looks like a band-aid and not a fix to me. regards, tom lane