I have this in my postgresql.conf file and it works fine (set the min to
whatever you want to log)
log_min_duration_statement = 3000 # -1 is disabled, in milliseconds.
Another setting that might get what you want:
#log_duration = false
uncomment and change to true.
From the docs:
(http://www.postgresql.org/docs/8.0/interactive/runtime-config.html)
Causes the duration of every completed statement which satisfies
log_statement to be logged. When using this option, if you are not using
syslog, it is recommended that you log the PID or session ID using
log_line_prefix so that you can link the statement to the duration using
the process ID or session ID. The default is off. Only superusers can
change this setting.
Brent Henry wrote:
Help! After recently migrating to Postgres 8, I've
discovered to my horror that I can't determine which
queries are poorly performing anymore because the
logging has drastically changed and no longer shows
durations for anything done through JDBC.
So I'm desperately trying to do performance tuning on
my servers and have no way to sort out which
statements are the slowest.
Does anyone have any suggestions? How do you
determine what queries are behaving badly when you
can't get durations out of the logs?
I have a perl script that analyzes the output from
Postgres 7 logs and it works great! But it relies on
the duration being there.
I did some searches on postgresql.org mailing lists
and have seen a few people discussing this problem,
but noone seems to be too worried about it. Is there
a simple work-around?
Sincerely,
Brent
____________________________________________________
Sell on Yahoo! Auctions – no fees. Bid on great items.
http://auctions.yahoo.com/
---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings
---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster
