Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1Xjt3N-0001WJ-Ba for pgsql-performance@arkaria.postgresql.org; Thu, 30 Oct 2014 16:58:29 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.80) (envelope-from ) id 1Xjt3M-0000fJ-L2 for pgsql-performance@arkaria.postgresql.org; Thu, 30 Oct 2014 16:58:28 +0000 Received: from makus.postgresql.org ([2001:4800:1501:1::229]) by malur.postgresql.org with esmtps (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1Xjt3L-0000fD-Kc for pgsql-performance@postgresql.org; Thu, 30 Oct 2014 16:58:27 +0000 Received: from resqmta-ch2-03v.sys.comcast.net ([2001:558:fe21:29:69:252:207:35]) by makus.postgresql.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.80) (envelope-from ) id 1Xjt3I-0004OA-7A for pgsql-performance@postgresql.org; Thu, 30 Oct 2014 16:58:25 +0000 Received: from resomta-ch2-08v.sys.comcast.net ([69.252.207.104]) by resqmta-ch2-03v.sys.comcast.net with comcast id 9UyN1p0082Fh1PH01UyNui; Thu, 30 Oct 2014 16:58:22 +0000 Received: from jerry.enova.com ([12.30.159.20]) by resomta-ch2-08v.sys.comcast.net with comcast id 9UyB1p00i0ShjPw01UyE7E; Thu, 30 Oct 2014 16:58:20 +0000 Received: by jerry.enova.com (Postfix, from userid 1001) id 9B4C87401ED; Thu, 30 Oct 2014 11:58:11 -0500 (CDT) From: Jerry Sievers To: jmcdonagh Cc: pgsql-performance@postgresql.org Subject: Re: Incredibly slow restore times after 9.0>9.2 upgrade References: <1414529739004-5824701.post@n5.nabble.com> <1414686202058-5825052.post@n5.nabble.com> Date: Thu, 30 Oct 2014 11:58:11 -0500 In-Reply-To: <1414686202058-5825052.post@n5.nabble.com> (jmcdonagh's message of "Thu, 30 Oct 2014 09:23:22 -0700 (PDT)") Message-ID: <86k33hwl3w.fsf@jerry.enova.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1414688302; bh=ztoYyx/axQJnmvS1DiuRhJR0B0JuwHVremzorhoEwOI=; h=Received:Received:Received:From:To:Subject:Date:Message-ID: MIME-Version:Content-Type; b=PwfoLvcXNlplWQNy1PdipfjlhsGEyr1HqZnkXlEXqFqxgg7t/8ftYDL3zkOaDM1kI wCj+ML4czgqTADqNUPHRFs4rkjImWGU1MWM42R4a56RxWRObT3Io9G9Sr1JJGnwvKU hlPA3XlrBIDFzEb8jNS7FuAj5+reSn6Ea6VRf1Bshwkr6mzuwAbvwSBM68JG8/sAPp 2Dya4+935RbzEXPAuGF5hgc1J4QDvgJtbSSCa2ZBD7qrr1HExOQdJ2jlynwCtbxyv1 jeBCn2WPGKw2F+w2KmTBxHTMFXYI96jgit53I/GYN/n7Pm9OgUdptDIrHb+6yBvQ6o WbZz8OHWmbAsg== X-Pg-Spam-Score: -0.2 (/) List-Archive: List-Help: List-ID: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: X-Mailing-List: pgsql-performance Precedence: bulk Sender: pgsql-performance-owner@postgresql.org jmcdonagh writes: > I just had a thought- I know some of these tables are in need of a vacuuming. > Could it be that the dump is dumping a bunch of garbage that the restore has > to sift through on the restore? I don't know enough details to know if this > is a dumb thought or not. No. However it's true that the dump will take a bit longer having to scan a bloated table rather than a tight one. Dump will only output the live rows. psql or pg_restore whatever you're using on the target side will not have to step over any junk. HTH > > The restore to RDS took roughly the same amount of time. My next move is to > try on a fast instance store, and also do a postgres 9 restore of a pure SQL > dump, but that won't really be a great test since I use custom format. I'm > assuming here that I can't take the custom dump from 9.2 and apply it to > 9.0, or can I? > > > > -- > View this message in context: http://postgresql.1045698.n5.nabble.com/Incredibly-slow-restore-times-after-9-0-9-2-upgrade-tp5824701p5825052.html > Sent from the PostgreSQL - performance mailing list archive at Nabble.com. -- Jerry Sievers Postgres DBA/Development Consulting e: postgres.consulting@comcast.net p: 312.241.7800 -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance