Re: fix log_min_duration_statement logic error - Mailing list pgsql-patches

From Bruce Momjian
Subject Re: fix log_min_duration_statement logic error
Date
Msg-id 200310041930.h94JUf014071@candle.pha.pa.us
Whole thread Raw
In response to Re: fix log_min_duration_statement logic error  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: fix log_min_duration_statement logic error  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: fix log_min_duration_statement logic error  (Christopher Kings-Lynne <chriskl@familyhealth.com.au>)
List pgsql-patches
Tom Lane wrote:
> Peter Eisentraut <peter_e@gmx.net> writes:
> > Bruce Momjian writes:
> >> LOG:  duration(secs): 0.000257
> >> LOG:  duration(secs): 0.000754
> >> LOG:  duration(secs): 0.008115 select * from pg_class;
>
> > I think the units typically go after the number.
>
> In any case, this is unnecessarily incompatible with everything else.
> EXPLAIN and psql's \timing show query durations in milliseconds.  And
> isn't log_min_duration_statement itself measured in milliseconds?
>
> I would prefer to see the log entries look like
>
>     LOG: query: select * from pg_class;
>     LOG: duration: nn.nnn msec
>
> in all cases, rather than moving information around depending on which
> combination of switches happens to have caused the log entries to be
> generated.  Am willing to fix the code to make this happen.

The problem with two lines is that another log message could get between
them.  I agree milliseconds makes more sense for output.

Maybe:

    LOG: duration: nn.nnn msec, select * from pg_class;

--
  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, Pennsylvania 19073

pgsql-patches by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: more spanish updates
Next
From: Tom Lane
Date:
Subject: Re: fix log_min_duration_statement logic error