pg.ddx.io  pgsql-performance@postgresql.org mailing list archive  
help / color / mirror / Atom feed
From: Erik Jones <erik@myemma.com>
To: pgsql-performance@postgresql.org
Subject: More 8.2 client issues (Was: [Slow dump?)
Date: Tue, 02 Jan 2007 15:59:04 -0600
Message-ID: <459AD5A8.7030102@myemma.com> (raw)

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 <erik@myemma.com>
To: 	Tom Lane <tgl@sss.pgh.pa.us>
CC: 	pgsql-performance@postgresql.org
References: 	<459A8B51.8000906@myemma.com> <5876.1167759024@sss.pgh.pa.us>



Tom Lane wrote:
> Erik Jones <erik@myemma.com> 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 <erik@myemma.com>
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 <erik@myemma.com>
software development
emma(r)




view thread (17+ messages)  latest in thread

Message-ID: <459AD5A8.7030102@myemma.com>
Permalink:  ../459AD5A8.7030102@myemma.com/
Also on:    postgresql.org/message-id/459AD5A8.7030102@myemma.com

 · 

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: pgsql-performance@postgresql.org
  Cc: erik@myemma.com
  Subject: Re: More 8.2 client issues (Was: [Slow dump?)
  In-Reply-To: <459AD5A8.7030102@myemma.com>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox