Received: from localhost (maia-5.hub.org [200.46.204.182]) by postgresql.org (Postfix) with ESMTP id D6D869FA0BA for ; Tue, 2 Jan 2007 17:59:18 -0400 (AST) Received: from postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.204.182]) (amavisd-new, port 10024) with ESMTP id 62500-02 for ; Tue, 2 Jan 2007 17:59:04 -0400 (AST) X-Greylist: from auto-whitelisted by SQLgrey-1.7.4 Received: from myemma.com (db1.e2ma.net [66.179.147.163]) by postgresql.org (Postfix) with ESMTP id 029F39F942B for ; Tue, 2 Jan 2007 17:59:06 -0400 (AST) Received: from localhost (localhost.localdomain [127.0.0.1]) by myemma.com (Postfix) with ESMTP id DBED323CFD for ; Tue, 2 Jan 2007 15:59:05 -0600 (CST) Received: from myemma.com ([127.0.0.1]) by localhost (velma [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 23635-01 for ; Tue, 2 Jan 2007 15:59:05 -0600 (CST) Received: from [10.0.23.39] (unknown [209.149.59.218]) by myemma.com (Postfix) with ESMTP id 4423F23D01 for ; Tue, 2 Jan 2007 15:59:05 -0600 (CST) Message-ID: <459AD5A8.7030102@myemma.com> Date: Tue, 02 Jan 2007 15:59:04 -0600 From: Erik Jones User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: pgsql-performance@postgresql.org Subject: More 8.2 client issues (Was: [Slow dump?) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at myemma.com X-Virus-Scanned: Maia Mailguard 1.0.1 X-Archive-Number: 200701/27 X-Sequence-Number: 22628 Hmm... This gets stranger and stranger. When connecting to the database with the psql client in 8.2's bin directory and using commands such as \d the client hangs, or takes an extremely long time. If we connect to the same 8.2 database with a psql client from 8.1.4, both remotely and locally, \d responds immediately. Could the issue be with the client programs somehow? Note also that we did our migration over the xmas weekend using the dump straight into a restore command. We kicked it off Saturday (12-23-06) night and it had just reached the point of adding foreign keys the morning of the 26th. We stopped it there, wrote a script to go through and build indexes (which finished in a timely manner) and have added just the foreign keys strictly necessary for our applications functionality (i.e. foreign keys set to cascade on update/delete, etc...). -------- Original Message -------- Subject: Re: [PERFORM] Slow dump? Date: Tue, 02 Jan 2007 11:40:18 -0600 From: Erik Jones To: Tom Lane CC: pgsql-performance@postgresql.org References: <459A8B51.8000906@myemma.com> <5876.1167759024@sss.pgh.pa.us> Tom Lane wrote: > Erik Jones writes: > >> Hello, we recently migrated our system from 8.1.x to 8.2 and when >> running dumps have noticed an extreme decrease in speed where the dump >> is concerned (by more than a factor of 2). >> > > That's odd. pg_dump is normally pretty much I/O bound, at least > assuming your tables are sizable. The only way it wouldn't be is if you > have a datatype with a very slow output converter. Have you looked into > exactly which tables are slow to dump and what datatypes they contain? > (Running pg_dump with log_min_duration_statement enabled would provide > useful data about which steps take a long time, if you're not sure.) > > regards, tom lane > Well, all of our tables use pretty basic data types: integer (various sizes), text, varchar, boolean, and timestamps without time zone. In addition, other than not having a lot of our foreign keys in place, there have been no other schema changes since the migration. -- erik jones software development emma(r) ---------------------------(end of broadcast)--------------------------- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to majordomo@postgresql.org so that your message can get through to the mailing list cleanly -- erik jones software development emma(r)