From: | "ktm(at)rice(dot)edu" <ktm(at)rice(dot)edu> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Ants Aasma <ants(at)cybertec(dot)at>, Greg Smith <greg(at)2ndquadrant(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Patch: add timing of buffer I/O requests |
Date: | 2012-04-10 18:07:21 |
Message-ID: | 20120410180721.GR24468@aart.rice.edu |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, Apr 10, 2012 at 02:01:02PM -0400, Robert Haas wrote:
> On Tue, Apr 10, 2012 at 1:58 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> > Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> >> On Tue, Apr 10, 2012 at 1:44 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2012-04-10 18:10:03 | Re: Patch: add timing of buffer I/O requests |
Previous Message | Robert Haas | 2012-04-10 18:01:02 | Re: Patch: add timing of buffer I/O requests |