On 4/10/12 5:07 PM, Greg Smith wrote:
I'd prefer to see at least usec resolution and 8 bytes of "dynamic range" for
query related statistics. Any of these would be fine from a UI perspective to me:
-float8 seconds
-float8 msec
-float8 usec
-int8 usec
I don't think int8 msec will be enough resolution to time queries for very
long, if it's not already obsolete. The committed example for pg_test_timing
on good hardware already clocks trivial events at a single usec. Even I/O is
getting there. I've measured my Fusion-io loaner card peaking at 8GB/s, which
works out to 1 usec per 8K page. None of that is even price no object hardware
today; it's the stuff sitting in my office.
If anything, I'd expect more timing code in the database that only has ms
resolution right now will start looking fat in a year or two, and more things
might need to be shifted to usec instead. Checkpoint timing can survive having
less resolution because its primary drumbeat is very unlikely to drop below the
minutes range.
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.
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.
--
Jim C. Nasby, Database Architect j...@nasby.net
512.569.9461 (cell) http://jim.nasby.net
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
