Re: Increasing the length of

On Wednesday 01 December 2004 03:38, 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.
>

it's what we started with and has some use cases that
log_min_duration_statement doesnt. Besides, if you change
log_min_duration_statement to print at the time duration is exceeded, you'll
need something to enable printing out of durations of completed statements.

> 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.
>

pg_stat_activity shows query_start, you could poll that to look for rouge
queries. you can also use log_min_duration_statement to watch for rouge
queries.

> My preference would be to do the following:
> - add a script to contrib to process the log file

check out the pqa project on pgfoundry

> - always add processid to log_statement_prefix when both log_statement
> and log_duration are specified, so you can always tie up the data
>

we have the option to add the process id now, I don't see why we should force
it into the line. besides, some logging tools will do this for you, so it
would be duplicate data.

--
Robert Treat
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL