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

From Andrew Dunstan
Subject Re: fix log_min_duration_statement logic error
Date
Msg-id 3F8035D7.6070209@dunslane.net
Whole thread Raw
In response to Re: fix log_min_duration_statement logic error  (Bruce Momjian <pgman@candle.pha.pa.us>)
List pgsql-patches

Bruce Momjian wrote:

>
>
>>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?
>>
>>
>
>Not sure.  I think the microsecond stuff is accurate to some degree, but
>not sure how much.  I think the tick is 10ms, but I thought the timing
>was much more accurate than that.
>
>
>
On my (slow) linux box the apparent time delay between 2 immediately
successive calls to gettimeofday() is 3 or 4 microsecs.

Presumably the clock tick is something much larger than that - I forget
where to look to find that out.

I think the real question is what granularity of reporting will be most
useful. For the session duration patch I restricted it to 1/100th of a
second, and didn't bother rounding the last place there because it
wasn't worth it (I thought). For query duration presumably something
smaller seems appropriate,  but I'm not sure how small. I suspect
anything much below a millisec (or at most 100 microsecs) is of
comparatively little value. OTOH truncating it is also probably of
little value - if you can read 3 or 4 decimal places you can read 6 just
as easily - just be aware that the low values have little information value.

cheers

andrew


pgsql-patches by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: fix log_min_duration_statement logic error
Next
From: Tom Lane
Date:
Subject: Re: fix log_min_duration_statement logic error