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.

unfortunately I am getting DNS errors from that site right now. I do have a copy of their code if you need it.


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

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.


-----Original Message-----
From: Tom Lane [mailto:[EMAIL PROTECTED]
Sent: Tuesday, August 16, 2005 10:02 PM
To: Barry Lind
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?


---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster

Reply via email to