Re: Patch: add timing of buffer I/O requests - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Patch: add timing of buffer I/O requests
Date
Msg-id 27804.1334355755@sss.pgh.pa.us
Whole thread Raw
In response to Re: Patch: add timing of buffer I/O requests  (Jim Nasby <jim@nasby.net>)
Responses Re: Patch: add timing of buffer I/O requests  (Greg Smith <greg@2ndQuadrant.com>)
List pgsql-hackers
Jim Nasby <jim@nasby.net> writes:
> I agree that ms is on it's way out... and frankly it wouldn't surprise me if at some point we actually had need of ns
resolution.

> Given that, I don't think ms or us definitions make sense... float8 seconds seams much more logical to me.

Well, the important point is that it be float8, so that fractions of
whatever units you choose can be represented.  I do not feel a strong
need to change the units in all the existing pg_stat_ columns from msec
to sec; that strikes me as just breaking things to little gain.  If the
majority of them were in sec then I'd want to converge on that, but
since the majority are in msec it seems like the path of least breakage
is to converge on that.

> Though, if we're going to end up seriously breaking things anyway,
> perhaps it would make sense to switch everything over to interval... I
> realize that there's more overhead there, but I don't think selecting
> from the stats views is exactly performance critical.

But (a) I *don't* want to seriously break things, and don't see a need
to; (b) interval is expensive and has got its own problems, notably an
internal limitation to usec resolution that we would not be able to get
rid of easily.  It's not even apparent to me that interval is
semantically The Right Thing for values that represent an accumulation
of a lot of different measurements.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Peter Eisentraut
Date:
Subject: Re: typo fix
Next
From: Robert Haas
Date:
Subject: Re: [BUGS] BUG #6572: The example of SPI_execute is bogus