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...
float8 vs int8 is a distinct issue, and probably one that is not as
much of an impact on clients if we change it. It is not hard to predict
that somebody will eventually want sub-msec resolution on these things,
which would suggest that float8 would be the better idea. But perhaps
we could leave that change for a future release.
regards, tom lane
