Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1Z72nu-0007kM-Qb for pgsql-admin@arkaria.postgresql.org; Mon, 22 Jun 2015 14:34:30 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.84) (envelope-from ) id 1Z72nu-0004YI-2w for pgsql-admin@arkaria.postgresql.org; Mon, 22 Jun 2015 14:34:30 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.84) (envelope-from ) id 1Z72li-0002cS-63 for pgsql-admin@postgresql.org; Mon, 22 Jun 2015 14:32:14 +0000 Received: from mout.web.de ([212.227.15.3]) by magus.postgresql.org with esmtps (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.84) (envelope-from ) id 1Z72la-0004UW-Ih for pgsql-admin@postgresql.org; Mon, 22 Jun 2015 14:32:13 +0000 Received: from vm-mailsrv.lan.net ([87.152.20.113]) by smtp.web.de (mrweb004) with ESMTPSA (Nemesis) id 0MgIMg-1ZUk1V22tC-00NjCH for ; Mon, 22 Jun 2015 16:32:03 +0200 Received: from localhost (localhost [127.0.0.1]) by vm-mailsrv.lan.net (Postfix) with ESMTP id 3406966B for ; Mon, 22 Jun 2015 16:32:03 +0200 (CEST) X-Spam-Flag: NO X-Spam-Score: -2.899 X-Spam-Level: X-Spam-Status: No, score=-2.899 tagged_above=-99.9 required=6.31 tests=[ALL_TRUSTED=-1, BAYES_00=-1.9, FREEMAIL_FROM=0.001] autolearn=ham autolearn_force=no Received: from vm-mailsrv.lan.net ([127.0.0.1]) by localhost (vm-mailsrv.lan.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W5E2EWFl5LrV for ; Mon, 22 Jun 2015 16:32:00 +0200 (CEST) Received: from neslonek.homeunix.org (vm-webapp-ext.dmz-lan.net [192.168.0.100]) by vm-mailsrv.lan.net (Postfix) with ESMTP id E8506F12E for ; Mon, 22 Jun 2015 16:31:59 +0200 (CEST) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Date: Mon, 22 Jun 2015 16:31:59 +0200 From: Jan Lentfer To: Subject: Re: =?UTF-8?Q?pg=5Fupgrade?= In-Reply-To: <1102220903.20150622162153@workfile.de> References: <1862034146.20150622111438@workfile.de> <5587E6F9.50702@afilias.info> <1102220903.20150622162153@workfile.de> Message-ID: X-Sender: Jan.Lentfer@web.de User-Agent: Roundcube Webmail/0.7.2 X-Provags-ID: V03:K0:Jh55GIq/tplyt3sAQM6hS5VEidFaSOUgsj75fcqBL13HU74RrEP rxEX3y8I6MNemYOsAM7cgtM+2x8D9vmGbKqajxTrL8LgDOzvAdeXFruDbjaKRGbIsnoSBEJ DeZp6LWxSD6PlYbmFFRyHks9MXJSOC18mg1SeDtENOJ60HSp1BueuiZAoG4kHPZJLPH9SOG Pwz3bNLhiFsYhBBqbRt/A== X-UI-Out-Filterresults: notjunk:1; X-Pg-Spam-Score: -3.3 (---) List-Archive: List-Help: List-ID: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: X-Mailing-List: pgsql-admin Precedence: bulk Sender: pgsql-admin-owner@postgresql.org Am 2015-06-22 16:21, schrieb Rainer Leo: >>>> we are still using PostgreSQL 9.0.2 on Windows Server. > >>>> Now we are migrating to Windows Server 2012 R2 and we >>>> would like to migrate PostgreSQL at the same time to >>>> the current version 9.4.4-1 > >>>> Which is the best way to migrate the data? > >>>> 1. pg_dump on the old server >>>> 2. pg_retore on the new server >>>> 3. pg_upgrade on the new server > >>>> Is this correct or is there a "best procedure" to do this? > >>> You do either 1 + 2 OR 3. pg_upgrade is binary upgrade, where as >>> pg_dump + pg_restore is "logical" (dump data and schemal to SQL >>> instructions). If you go that way also check pg_dumpall for dumping >>> the globals. > > >>> Regards > >>> Jan > > >> Also, for 1+2 you would be advised to do the pg_dump/restore using >> the >> *new* binaries (9.4), things could get tricky otherwise... > >> Ziggy > > Thanks for your help. > > Using the 9.4 pg_dump on the old server did not work (missing > libintl-8.dll), so I used the 9.0 pg_dump. > > pg_restore on the new server worked fine, BUT the perfomance is > lousy, for example a query that took 1732ms on the old server now > takes longer than 32000ms every time on 9.4 > > I tuned the postgres.conf exactly like the old one, except for more > RAM in some parameters. > > Does this mean I have to install 9.4 on the old server so I can use > pg_upgrade? That won't make a difference regarding resulting performance. Did you run ANALYZE after pg_restore? Also, did you run the query more than once? The new system is "cold" (caches are empty). It will take some time (depends on your amount of data and RAM, etc) until everything is properly loaded. Did you compare EXPLAIN outputs on both systems (only makes sense after running ANALYZE)? Do the systems differ in any other way, especially storage? Jan -- Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-admin