Re: More 8.2 client issues (Was: [Slow dump?)
От | Erik Jones |
---|---|
Тема | Re: More 8.2 client issues (Was: [Slow dump?) |
Дата | |
Msg-id | 459BDC98.8030008@myemma.com обсуждение исходный текст |
Ответ на | Re: More 8.2 client issues (Was: [Slow dump?) (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: More 8.2 client issues (Was: [Slow dump?)
Re: More 8.2 client issues (Was: [Slow dump?) |
Список | pgsql-performance |
Tom Lane wrote: > 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? > Well, running "select count(*) from pg_class;" returns 524699 rows and our search path is the default. I'd also like to reiterate that \d pg_class returns instantly when run from the 8.1.4 psql client connected to the 8.2 db. How would I go about determining which backend server process psql was attached to? -- erik jones <erik@myemma.com> software development emma(r)
В списке pgsql-performance по дате отправления: