Re: Patch: add timing of buffer I/O requests - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Patch: add timing of buffer I/O requests
Date
Msg-id 12671.1334081403@sss.pgh.pa.us
Whole thread Raw
In response to Re: Patch: add timing of buffer I/O requests  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: Patch: add timing of buffer I/O requests  (Peter Geoghegan <peter@2ndquadrant.com>)
List pgsql-hackers
Robert Haas <robertmhaas@gmail.com> writes:
> On Tue, Apr 10, 2012 at 1:58 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> The business about underlying microseconds is maybe not so good, but
>> I don't think we want to touch that right now. �In the long run
>> I think it would make sense to converge on float8 msec as being the
>> standard for exposed timing values, because that is readily adaptable to
>> the underlying data having nsec or even better precision.

> Hmm.  Maybe we should think about numeric ms, which would have all the
> same advantages but without the round-off error.

Color me unimpressed ... numeric calculations are vastly more expensive
than float, and where are you going to get timing data that has more
than sixteen decimal digits of accuracy?  IME we're lucky to get three
repeatable digits in any timing measurement.  The point of using a
non-integer type here is not so much precision as dynamic range:
sometimes you might be measuring queries that run for hours, and other
times ones that run for microseconds.  In the latter case it's important
to be able to represent nanoseconds, but not so much in the former.
        regards, tom lane


pgsql-hackers by date:

Previous
From: "ktm@rice.edu"
Date:
Subject: Re: Patch: add timing of buffer I/O requests
Next
From: Tom Lane
Date:
Subject: Re: plpython triggers are broken for composite-type columns