To: Erik Jones <erik@myemma.com>
cc: pgsql-performance@postgresql.org
Subject: Re: More 8.2 client issues (Was: [Slow dump?) 
In-reply-to: <459BD61C.3030202@myemma.com> 
References: <459AD5A8.7030102@myemma.com> <22512.1167779361@sss.pgh.pa.us>
	<459BD61C.3030202@myemma.com>
Comments: In-reply-to Erik Jones <erik@myemma.com>
	message dated "Wed, 03 Jan 2007 10:13:16 -0600"
Date: Wed, 03 Jan 2007 11:24:39 -0500
Message-ID: <11617.1167841479@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

Erik Jones <erik@myemma.com> writes:
> ...
> sigaction(SIGPIPE, 0x08046E20, 0x08046E70)      = 0
> send(4, " Q\0\0\0E5 S E L E C T  ".., 230, 0)   = 230   
> <-----------------------------------------------------------  Hang is 
> right here!
> sigaction(SIGPIPE, 0x08046E20, 0x08046E70)      = 0
> pollsys(0x08046EE8, 1, 0x00000000, 0x00000000) (sleeping...)
> pollsys(0x08046EE8, 1, 0x00000000, 0x00000000)  = 1
> recv(4, " T\0\0\0 P\003 o i d\0\0".., 16384, 0) = 140
> ...

Hmph.  So it seems the delay really is on the server's end.  Any chance
you could truss the connected backend process too and see what it's doing?

Actually ... before you do that, the first query for "\d pg_class"
should look like

SELECT c.oid,
  n.nspname,
  c.relname
FROM pg_catalog.pg_class c
     LEFT JOIN pg_catalog.pg_namespace n ON n.oid = c.relnamespace
WHERE c.relname ~ '^(pg_class)$'
  AND pg_catalog.pg_table_is_visible(c.oid)
ORDER BY 2, 3;

I could see this taking an unreasonable amount of time if you had a huge
number of pg_class rows or a very long search_path --- is your database
at all out of the ordinary in those ways?

			regards, tom lane