Re: Patch: add timing of buffer I/O requests
Robert Haas <robertmhaas@gmail.com>
From: Robert Haas <robertmhaas@gmail.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Peter Geoghegan <peter@2ndquadrant.com>, Ants Aasma <ants@cybertec.at>, Greg Smith <greg@2ndquadrant.com>, pgsql-hackers@postgresql.org
Date: 2012-04-24T02:03:06Z
Lists: pgsql-hackers
On Sat, Apr 14, 2012 at 10:33 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Robert Haas <robertmhaas@gmail.com> writes: >> The internal representation doesn't have to be (and certainly >> shouldn't be) numeric. But if you translate to numeric before >> returning the data to the user, then you have the freedom, in the >> future, to whack around the internal representation however you like, >> without breaking backward compatibility. Choosing float8 for the >> external representation is fine as long as we're sure we're not ever >> going to want more than 16 significant digits, but I see no particular >> value in baking in that assumption. But perhaps, as the saying goes, >> 16 digits ought to be enough for anyone. > > 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. However, the main thing here is that we need to do *something* here... -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company