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

From Magnus Hagander
Subject Re: Patch: add timing of buffer I/O requests
Date
Msg-id CABUevExc4vrsa6-fCvC8bezKFnJV3A41ZgOQGNg7sKM=qQzBhg@mail.gmail.com
Whole thread Raw
In response to Re: Patch: add timing of buffer I/O requests  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: Patch: add timing of buffer I/O requests  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Tue, Apr 10, 2012 at 17:58, Robert Haas <robertmhaas@gmail.com> wrote:
> On Tue, Apr 10, 2012 at 10:06 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> Robert Haas <robertmhaas@gmail.com> writes:
>>> Hmm.  So, on further review, this is not as simple as it seems.  I'd
>>> like some input from other people on what we should do here.
>>
>>> pg_stat_statements has long exposed a column called "total_time" as a
>>> float8.  It now exposes columns "time_read" and "time_write" which are
>>> actually measuring the time spent reading and writing data blocks, and
>>> those are also exposed as a float8; all these count seconds.
>>
>>> Meanwhile, all times exposed by the stats collector (including the new
>>> and analagous pg_stat_database.block_read_time and
>>> pg_stat_database.block_write_time columns) are exposed as int8; these
>>> count milliseconds.
>>
>>> So, should we make the new columns exposed by pg_stat_statements use
>>> milliseconds, so that the block read/write timings are everywhere in
>>> milliseconds, or should we keep them as a float8, so that all the
>>> times exposed by pg_stat_statements use float8?
>>
>> Given that we've whacked pg_stat_statements' behavior around rather
>> thoroughly in this release, maybe we could get away with redefining
>> total_time as being measured in msec rather than sec, thereby aligning
>> units as msec across the board.  It's arguably a smaller deal than the
>> way we've redefined what the query column contains...
>
> Retyping columns is an awfully good way to produce grumpy users.  Then
> again, if we're going to do it, it would certainly be better to do it
> now rather than later, because right now I'm guessing
> pg_stat_statements is a lot less heavily used than it will be after
> 9.2 hits shelves.

Agreed. It's better if we can also change the name of it - provided we
can come up with a reasonable new name. Then peoples applications will
break *visibly*, which is a lot  better than breaking invisibly. (This
is the main reason why we renamed current_query in pg_stat_activity..)

--
 Magnus Hagander
 Me: http://www.hagander.net/
 Work: http://www.redpill-linpro.com/


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Patch: add timing of buffer I/O requests
Next
From: Tom Lane
Date:
Subject: Re: Patch: add timing of buffer I/O requests