On Tue, Apr 10, 2012 at 02:01:02PM -0400, Robert Haas wrote: > On Tue, Apr 10, 2012 at 1:58 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > > Robert Haas <robertmh...@gmail.com> writes: > >> On Tue, Apr 10, 2012 at 1:44 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > >>> Huh? I understood what you said upthread to be that we have two ways > >>> in existing releases (anything unreleased has zero standing in this > >>> discussion): float8 sec in pg_stat_statements.total_time, and > >>> int8 msec everywhere else. Did I miss something? > > > >> We also have int8 usec floating around. But even if we didn't, float8 > >> msec would be a new one, regardless of whether it would be third or > >> fourth... > > > > It would still be the second one, because it would replace the only use > > of float8 sec, no? And more to the point, it converges us on msec being > > the only exposed unit. > > > > 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. > > -- > Robert Haas > EnterpriseDB: http://www.enterprisedb.com > The Enterprise PostgreSQL Company >
They are also a lot bigger with tons of added overhead. :) Regards, Ken -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
