Yeah, I agree. this is not necessary, i will remove the commitfest at '2019-07-19'.
Tomas Vondra <tomas.von...@2ndquadrant.com> 于2019年7月12日周五 下午9:07写道： > 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 > >
