Barry,
One way to do this is to turn logging on for calls over a certain
duration
log_duration in the config file. This will only log calls over n
milliseconds.
There's a tool called iron eye SQL that monitors JDBC calls.
http://www.irongrid.com/
unfortunately I am getting DNS errors from that site right now. I do
have a copy of their code if you need it.
Dave
On 17-Aug-05, at 1:43 AM, Barry Lind wrote:
That was my suspicion as well, which is why I tried the V2 protocol.
I do not know of any specific queries that are causing the
problem. As
I monitor 'top' I see processes utilizing a significant amount of CPU
running SELECT, UPDATE and DELETE, which would lead me to believe that
it isn't any one specific query.
How does one identify on a live system specific queries that are
running
slow, especially with the V3 protocol and when the system is executing
about a 100 queries a second (which makes turning on any sort of
logging
very very verbose)? (I just subscribed to the performance list, so
this
is probably something that has been answered many times before on this
list).
I haven't tried to track down a performance problem like this
before on
postgres. Since most of our large customers run Oracle that is
where I
have the knowledge to figure something like this out.
Thanks,
--Barry
-----Original Message-----
From: Tom Lane [mailto:[EMAIL PROTECTED]
Sent: Tuesday, August 16, 2005 10:02 PM
To: Barry Lind
Cc: pgsql-performance@postgresql.org; pgsql-jdbc@postgresql.org
Subject: Re: [JDBC] Performance problem using V3 protocol in jdbc
driver
"Barry Lind" <[EMAIL PROTECTED]> writes:
... On a hunch I switched the jdbc driver to using the V2 protocol
and the load on the machine dropped down to what it was when using
Oracle and everything was fine.
First knee-jerk reaction is that it's an optimization problem stemming
from V3 protocol feeding parameterized queries to the backend where V2
did not, and the planner being unable to cope :-(
Can you identify the specific queries causing the problem?
regards, tom lane
---------------------------(end of
broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster
