Re: fix log_min_duration_statement logic error

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Peter Eisentraut <peter_e(at)gmx(dot)net>
Cc: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>, Neil Conway <neilc(at)samurai(dot)com>, PostgreSQL Patches <pgsql-patches(at)postgresql(dot)org>
Subject: Re: fix log_min_duration_statement logic error
Date: 2003-10-05 16:17:48
Message-ID: 997.1065370668@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-patches

Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
> Btw., I was wondering, are we kidding ourselves when we display
> microsecond precision to the user? What accuracy do these measurements
> have in respect to what they are actually supposed to measure?

<shrug> The operating system API we are using is spec'd at microsecond
precision. It's likely on any given hardware that some of the low order
digits might be bogus, but it is not our business to guess how many.
If we throw away low-order digits we may be losing useful information.
(This becomes more and more likely as machines get faster.)

We have EXPLAIN ANALYZE output showing two fractional digits of msec,
so it is discarding one potentially significant digit. I did that for
consistency with the historical behavior of showing two fractional
digits of cost estimates, but could probably be talked into the idea
that three digits should be shown instead.

BTW, EXPLAIN ANALYZE puts out

Total runtime: 406.53 msec

Do you want to make an exception to the string freeze to change this
to "ms"?

regards, tom lane

In response to

Responses

Browse pgsql-patches by date

  From Date Subject
Next Message Tom Lane 2003-10-05 16:20:52 Re: fix log_min_duration_statement logic error
Previous Message Tom Lane 2003-10-05 16:10:41 Re: fix log_min_duration_statement logic error