On Fri, Jul 12, 2019 at 01:51:50PM +0900, Michael Paquier wrote:
>On Thu, Jul 11, 2019 at 04:34:20PM +0200, Daniel Verite wrote:
>> I can understand why you'd want that resetting the stats for a single object
>> would not reset the per-database timestamp, but this would revert a 8+ years
>> old decision that seems intentional and has apparently not been criticized
>> since then (based on searching for pg_stat_reset_single_table_counters in
>> the archives) . More opinions are probably needed in favor of this
>> change (or against, in which case the fate of the patch might be a
>> rejection).
>
>I agree with Daniel that breaking an 8-year-old behavior may not be of
>the taste of folks relying on the current behavior, particularly
>because we have not had complains about the current behavior being
>bad. So -1 from me.
Yeah, I agree. There are several reasons why it's done this way:
1) overhead
Now we only store a two timestamps - for a database and for bgwriter. We
could track a timestamp for each object, of course ...
2) complexity
Updating the timestamps would be fairly simple, but what about querying
the data? Currently you fetch the data, see if the stats_reset changed
since the last snapshot, and if not you're good. If it changed, you know
some object (or the whole db) has reset counters, so you can't rely on
the data being consistent.
If we had stats_reset for each object, figuring out which data is still
valid and what has been reset would be far more complicated.
But reseting stats is not expected to be a common operation, so this
seemed like an acceptable tradeoff (and I'd argue it still is).
regards
--
Tomas Vondra http://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services