On Sat, Apr 14, 2012 at 9:54 AM, Peter Geoghegan <peter@2ndquadrant.com> wrote:
> On 10 April 2012 19:10, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>>> 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?
>
> +1
>
> Besides, how do you propose to solve the problem of storing numerics
> in a fixed allocation of shared memory? The only comparable thing in
> pg_stat_statements is the query string, which is capped at
> track_activity_query_size bytes for this very reason.
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.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
