How difficult would it be to make the combination log_statement = all log_duration = true
just put the duration on the same line as the statement? Then log_min_duration_statement could be used to do the desired log-at-threshold behavior, which certainly seems valuable. You'd need a way to visually/scriptually (?) distinguish those log records, though, I guess. Note that my original post on this was more of a question than an objection - it's entirely possible to sed around having duration and statement on separate lines - I just wanted clarification. Having them on the same line IS handy, however.... - DAP >-----Original Message----- >From: Bruce Momjian [mailto:[EMAIL PROTECTED] >Sent: Wednesday, December 01, 2004 11:18 AM >To: Simon Riggs >Cc: David Parker; [EMAIL PROTECTED] >Subject: Re: [HACKERS] Increasing the length of > >Simon Riggs wrote: >> On Tue, 2004-11-30 at 19:32, Bruce Momjian wrote: >> > David Parker wrote: >> > > I've been using "log_min_duration_statement = 0" to get >durations >> > > on all SQL statements for the purposes of performance tuning, >> > > because this logs the duration on the same line as the >statement. >> > > My reading of this TODO is that now >log_min_duration_statement = 0 >> > > would give me the statements but no total duration? >> > >> > Oh, sorry, you are right. I forgot about the duration >part! I got >> > so excited I forgot. >> > >> > TODO item removed. >> >> David's objection was noted, and why I hadn't coded it (yet). >> >> There are currently two ways of getting statement and >duration output, >> which is confusing.... >> >> You can either >> 1. Individual statements >> - log_statement = all >> - log_duration = true >> - log_line_prefix includes processid >> >> which produces 2 log lines like >> statement: xxxxxxxxx >> duration: yyyyyyyyyy >> >> 2. log_min_duration >> log_min_duration_statement=0 >> which produces 1 log line like >> duration: yyyyyyy statement: xxxxxxxxxx >> >> These two things do exactly the same thing, apart from the way the >> output is presented to the user in the log line. >> >> I'd like to change log_min_duration_statement as suggested, but this >> side-effect behaviour of being a better log_statement than >> log_statement kindof gets in the way. It makes me wonder why we have >> log_statement at all. > >We have it so you can look in the log to see currently running >queries rather than just completed queries. > >> We all want to do performance tracing. I'd also like to be able to >> dynamically monitor what is actually happening *now* on the system. >> There is no way right now to monitor for rogue queries, >other than to >> cancel anything that runs more than statement_timeout. Thats >not good >> either, even if it does keep the current behaviour. >> >> My preference would be to do the following: >> - add a script to contrib to process the log file >> - always add processid to log_statement_prefix when both >log_statement >> and log_duration are specified, so you can always tie up the data > >I think our setup is confusing enough. Adding "automatic" >additions seems even more confusing than what we have now. We >could throw a log warning message somehow though. > >-- > Bruce Momjian | http://candle.pha.pa.us > [EMAIL PROTECTED] | (610) 359-1001 > + If your life is a hard drive, | 13 Roberts Road > + Christ can be your backup. | Newtown Square, >Pennsylvania 19073 > ---------------------------(end of broadcast)--------------------------- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
