Re: psql performance - Mailing list pgsql-general
From | Joseph Shraibman |
---|---|
Subject | Re: psql performance |
Date | |
Msg-id | 425F4425.60805@selectacast.net Whole thread Raw |
In response to | Re: psql performance (Tom Lane <tgl@sss.pgh.pa.us>) |
Responses |
Re: psql performance
|
List | pgsql-general |
I'm sshing into my redhat 8 server and running psql 7.4.7. My client is fedora core 3. With konsole terminals I have the problem but with xterm I don't. I did a diff between the output of env of both of them and got: -SSH_CLIENT=66.xxx.xxx.124 32943 22 -SSH_TTY=/dev/pts/5 +SSH_CLIENT=66.xxx.xxx.124 33110 22 +SSH_TTY=/dev/pts/6 (I sanatized my ip) So the question what is the difference between konsole and xterm that is causing cpu to be eating up on the server? My ssh client: [jks@jks-desktop ~]$ ssh -V OpenSSH_3.9p1, OpenSSL 0.9.7a Feb 19 2003 server sshd: sshd version OpenSSH_3.4p1 server:> rpm -qa | grep readline readline-devel-4.3-3 readline-4.3-3 [jks@jks-desktop ~]$ rpm -qa | grep readline readline-4.3-13 readline-devel-4.3-13 Tom Lane wrote: > Joseph Shraibman <jks@selectacast.net> writes: > >>It doesn't matter what the query is. The problem happens before it even >>runs the query. > > > Hmmm ... I see different misbehavior (psql seems to lock up entirely, > it doesn't slow down or eat CPU). But it's still misbehavior. > > "psql -n" doesn't have a problem, which says that this is probably a > readline bug rather than our own bug. I think it's probably context > dependent too; I'm pretty sure I've pasted big queries into psql without > a problem while working directly on my work machine, but right now I'm > ssh'd into it from a laptop and I do see a problem. > > [ further experimentation... ] A local psql on the laptop doesn't > show a problem either. Both this and the one on the work machine > are 8.1devel using readline-4.2a, so it doesn't seem to be an issue > of different software versions. Maybe readline doesn't like ssh? > > [ still further experimentation... ] No, because ssh'ing to my *other* > work machine and running psql there doesn't show a problem either. > Curiouser and curiouser. But it's clearly very context dependent. > > You should probably tell us *exactly* what you are running, in every bit > of software between you and psql. My tests here are with (local) Mac OS > X 10.3.8, Apple-supplied X server and xterm terminal, Apple-supplied ssh > (seems to be 3.6.1p1), local psql is current PG sources + readline 4.2a. > The remote that doesn't work nicely is HPUX 10.20, sshd is > openssh-3.7.1p2, current psql sources, readline 4.2a. The remote that > does work nicely is Fedora Core 3, sshd 3.9p1-8.0.1, current psql > sources, readline 4.3-13. I'm not seeing a pattern ... > > >>Incidentally when I did that I only got back one row. What's up with that? > > > UNION eliminates duplicates. > > regards, tom lane > > ---------------------------(end of broadcast)--------------------------- > TIP 9: the planner will ignore your desire to choose an index scan if your > joining column's datatypes do not match
pgsql-general by date: