Re: Patch: add timing of buffer I/O requests

From: Jim Nasby <jim(at)nasby(dot)net>
To: Greg Smith <greg(at)2ndQuadrant(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Magnus Hagander <magnus(at)hagander(dot)net>, Robert Haas <robertmhaas(at)gmail(dot)com>, Ants Aasma <ants(at)cybertec(dot)at>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Patch: add timing of buffer I/O requests
Date: 2012-04-13 20:38:09
Message-ID: 4F888EB1.2030703@nasby.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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 jim(at)nasby(dot)net
512.569.9461 (cell) http://jim.nasby.net

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Eisentraut 2012-04-13 20:48:06 Re: Last gasp
Previous Message Peter Geoghegan 2012-04-13 20:33:42 Re: Patch: add timing of buffer I/O requests