Robert Haas <robertmh...@gmail.com> writes:
> I like the idea of including the word block in there. I don't think
> it was probably a terribly good idea to abbreviate that to blk
> everywhere, but at this point it's probably better to be consistent,
> sigh.
> As for track_iotiming -> track_io_timing, I'm fine with that as well.
I made these changes, so I think we are done with the naming issues.
However, I'd still like to propose that we think about adjusting the
timing column datatypes, ie uniformly use float8 msec for values
representing elapsed times. By my count there are six columns that
would be affected:
pg_stat_bgwriter.checkpoint_write_time
pg_stat_bgwriter.checkpoint_sync_time
pg_stat_database.blk_read_time
pg_stat_database.blk_write_time
pg_stat_user_functions.total_time
pg_stat_user_functions.self_time
The first four of these are new in 9.2, meaning that we would only be
creating a compatibility issue for the last two. If we wait to do this
in the future, we will have a significantly bigger problem than if we
do it today. Advantages of the change are:
* Better precision exposed to the user (pg_stat_user_functions has
historically provided only millisecond precision).
* Removal of arbitrary limit of microsecond precision. Of course,
the underlying data is still no better than microsecond, but if we
ever are able to migrate to OS APIs that return better-than-microsecond
data, we won't have to adjust the stats view APIs to expose that data.
* A chance to make the functions underlying these stats view columns
agree with the exposed column definitions.
Any objections out there?
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
