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

From: Magnus Hagander <magnus(at)hagander(dot)net>
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 16:13:44
Message-ID: CABUevExc4vrsa6-fCvC8bezKFnJV3A41ZgOQGNg7sKM=qQzBhg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Apr 10, 2012 at 17:58, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> On Tue, Apr 10, 2012 at 10:06 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> Robert Haas <robertmhaas(at)gmail(dot)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/

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2012-04-10 16:27:11 Re: Patch: add timing of buffer I/O requests
Previous Message Tom Lane 2012-04-10 16:11:00 Re: Patch: add timing of buffer I/O requests