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

From Robert Haas
Subject Re: Patch: add timing of buffer I/O requests
Date
Msg-id CA+TgmoZ7Tuz3zevkMBN8Oh9HXXN2tLXY-8T6Z_N0jh-Yb1_Kvg@mail.gmail.com
Whole thread Raw
In response to Re: Patch: add timing of buffer I/O requests  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Patch: add timing of buffer I/O requests  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Wed, Apr 25, 2012 at 12:47 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
>> On Sat, Apr 14, 2012 at 10:33 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>>> There's no particular reason to think that Moore's Law is going to
>>> result in an increase in the fractional precision of timing data.
>>> It hasn't done so in the past, for sure.
>
>> Perhaps, but nobody's explained what we gain out of NOT using numeric.
>>  "It's slow" doesn't impress me; selecting from a system view doesn't
>> need to be lightning-fast.
>
> Well, how about "the code is going to be quite a lot less readable"?
> C can manipulate floats natively, but not numerics.
>
> Also, as was pointed out upthread, the underlying data in shared memory
> is almost certainly never going to be infinite-precision; so using
> numeric in the API seems to me to be more likely to convey a false
> impression of exactness than to do anything useful.
>
>> However, the main thing here is that we need to do *something* here...
>
> Agreed, this has got to be pushed forward.

In the interest of furthering that goal, I propose that whoever is
willing to take the time to clean this up gets to decide what to
standardize on, and I'm happy to give you first crack at that if you
have the cycles.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company


pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: Temporary tables under hot standby
Next
From: Tom Lane
Date:
Subject: Re: Patch: add timing of buffer I/O requests