On Sat, Apr 14, 2012 at 9:54 AM, Peter Geoghegan <pe...@2ndquadrant.com> wrote: > On 10 April 2012 19:10, Tom Lane <t...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
