Обсуждение: instrumenting the driver
There has been a request to instrument the driver for measuring timing. One mechanism that comes to mind is to allow one listener in execute, etc. Or to simply measure it ourselves. Any comments? Dave Cramer davec@postgresintl.com www.postgresintl.com ICQ #14675561 jabber davecramer@jabber.org ph (519 939 0336 )
The first thing that comes to mind is to check the DriverManager.getLogWriter() value at key points in the code. If not null, log timing info along with other logging/tracing info. Would this satisfy the request? -Kevin >>> Dave Cramer <pg@fastcrypt.com> 06/17/05 6:59 AM >>> There has been a request to instrument the driver for measuring timing. One mechanism that comes to mind is to allow one listener in execute, etc. Or to simply measure it ourselves. Any comments? Dave Cramer davec@postgresintl.com www.postgresintl.com ICQ #14675561 jabber davecramer@jabber.org ph (519 939 0336 ) ---------------------------(end of broadcast)--------------------------- TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org
Dave Cramer wrote: > There has been a request to instrument the driver for measuring timing. > > One mechanism that comes to mind is to allow one listener in execute, > etc. Or to simply measure it ourselves. I rather like the `dtrace` approach in Solaris 10.. It provides instrument hooks for all kinds of stuff but the hooks do nothing if nothing has hooked them (presumably implemented with an inline macro of some kind). The dtrace utility has a wide range of timing, counting, classification, etc statistics gathering capabilities. Solaris 10 has hooks on virtually every system routine entry and exit, as well as many other things. Now, obviously, thats a lot more sophisticated than we'd want to bite off in a jdbc driver, but the idea of a generalized hook on entry and exit of each major method is a good one, the user routine that hooks these could classify the statement being executed if it wanted to (at its own expense, naturally)