Re: Increasing the length of

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:pgman(at)candle(dot)pha(dot)pa(dot)us]
>Sent: Wednesday, December 01, 2004 11:18 AM
>To: Simon Riggs
>Cc: David Parker; pgsql-hackers(at)postgresql(dot)org
>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
> pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
> + If your life is a hard drive, | 13 Roberts Road
> + Christ can be your backup. | Newtown Square,
>Pennsylvania 19073
>