> >>> Now I've a second thought: what do you think about resetting the related > >>> number > >>> of operations and *_time fields when enabling/disabling track_io_timing? > >>> (And mention it in the doc). > >>> > >>> That way it'd prevent bad interpretation (at least as far the time per > >>> operation metrics are concerned). > >>> > >>> Thinking that way as we'd loose some (most?) benefits of the new *_time > >>> columns > >>> if one can't "trust" their related operations and/or one is not sampling > >>> pg_stat_io frequently enough (to discard the samples > >>> where the track_io_timing changes occur). > >>> > >>> But well, resetting the operations could also lead to bad interpretation > >>> about the operations... > >>> > >>> Not sure about which approach I like the most yet, what do you think? > >> > >> Oh, this is an interesting idea. I think you are right about the > >> synchronization issues making the statistics untrustworthy and, thus, > >> unuseable. > > > > No, I don't think we can do that. It can be enabled on a per-session basis.
> Oh right. So it's even less clear to me to get how one would make use of > those new *_time fields, given that: > - pg_stat_io is "global" across all sessions. So, even if one session is > doing some "testing" and needs to turn track_io_timing on, then it > is even not sure it's only reflecting its own testing (as other sessions may > have turned it on too). > - There is the risk mentioned above of bad interpretations for the "time per > operation" metrics. > - Even if there is frequent enough sampling of it pg_stat_io, one does not > know which samples contain track_io_timing changes (at the cluster or session > level). As long as track_io_timing can be toggled, blk_write_time could lead to wrong conclusions. I think it may be helpful to track the blks_read when track_io_timing is enabled Separately. blks_read will be as is and give the overall blks_read, while a new column blks_read_with_timing will only report on blks_read with track_io_timing enabled. blks_read_with_timing should never be larger than blks_read. This will then make the blks_read_time valuable if it's looked at with the blks_read_with_timing column. Regards, -- Sami Imseih Amazon Web Services (AWS)
