Re: Increasing the length of - Mailing list pgsql-hackers

From Bruce Momjian
Subject Re: Increasing the length of
Date
Msg-id 200412011617.iB1GHqD03101@candle.pha.pa.us
Whole thread Raw
In response to Re: Increasing the length of  (Simon Riggs <simon@2ndquadrant.com>)
List pgsql-hackers
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@candle.pha.pa.us               |  (610)
359-1001+  If your life is a hard drive,     |  13 Roberts Road +  Christ can be your backup.        |  Newtown Square,
Pennsylvania19073
 


pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: libpq and psql not on same page about SIGPIPE
Next
From: "Cason, Kenny"
Date:
Subject: Where is the connection info