On Tue, Apr 10, 2012 at 18:27, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Magnus Hagander <magnus@hagander.net> writes:
>> 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:
>>>> 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..)
>
> That might be overkill. Changing the column name will definitely break
> anything more specific than "select * from pg_stat_statements".
> However, it's less clear that changing the units in which the column is
> expressed will break things. It seems likely to me that nobody out
> there is doing anything much more sophisticated than sorting by the
> column, and that's still going to work the same.
I've seen cases where the timing is correlated with external timings,
e.g. from the application. Have I seen it a lot? No - but then I
haven't seen a big usage of pg_stat_statements either, which might be
the better argument for allowing a change of unit but not name.
--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/
