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