On Thu, Apr 14, 2005 at 11:05:37PM -0400, Joseph Shraibman wrote:
> Incidentally when I did that I only got back one row. What's up with that?
That's PostgreSQL acting according to ANSI SQL. If you want multiple
rows, you need UNION ALL.
--
Jim C. Nasby, Database Consultant [EMAIL
Uwe C. Schroeder wrote:
Don't see a problem pasting this one.
Neither to a local nor to a remote ssh (running psql certainly).
This is 7.4.7 on redhat and mandrake linux'es
I'd suspect it has nothing to do with psql. Can you paste that into a normal
ssh / terminal ?
It is slow just pasting to the
Joseph Shraibman wrote:
So the question what is the difference between konsole and xterm that is
causing cpu to be eating up on the server?
Scratch that. I wasn't using the same input for both queries. Both of
them are slow.
I discovered that adding newlines to the query speeds things up a lo
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.
Don't see a problem pasting this one.
Neither to a local nor to a remote ssh (running psql certainly).
This is 7.4.7 on redhat and mandrake linux'es
I'd suspect it has nothing to do with psql. Can you paste that into a normal
ssh / terminal ?
On Thursday 14 April 2005 20:05, Joseph Shraibman w
On Thu, Apr 14, 2005 at 08:17:55PM -0700, Joshua D. Drake wrote:
> Joseph Shraibman wrote:
> >It doesn't matter what the query is. The problem happens before it even
> >runs the query. Just try pasting select
> >'aaa' union select
> >'aaa
On Thu, Apr 14, 2005 at 11:05:37PM -0400, Joseph Shraibman wrote:
> It doesn't matter what the query is. The problem happens before it even
> runs the query.
This is most certainly a problem with the shell or the terminal. I have
seen this effect somewhere else, but I can't reproduce it with ps
Joseph Shraibman 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
Joseph Shraibman wrote:
It doesn't matter what the query is. The problem happens before it even
runs the query. Just try pasting select
'aaa' union select
'aaa' union select
'aaa' union
It doesn't matter what the query is. The problem happens before it even
runs the query. Just try pasting select
'aaa' union select
'aaa' union select
'aaa' union select
'aa
The cpu on the remote server is being used up by psql, and my shell is
local.
Paul Tillotson wrote:
I am not sure if this is relevant, but I think it may depend on what
kind of shell you are using. I use putty on windows XP, and it seemed
to me that when I had the encoding set to Latin-1, it a
I am not sure if this is relevant, but I think it may depend on what
kind of shell you are using. I use putty on windows XP, and it seemed
to me that when I had the encoding set to Latin-1, it always pasted very
fast, but when I had it set to UTF8, the paste would be slow. I
concluded (perha
What is the query?
What is the schema for the tables in the query?
What is the cardinality of the tables?
What does the planner say, when you do this:
explain
explain analyze
http://www.faqs.org/docs/ppbook/r26943.htm
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]
13 matches
Mail list logo
