Re: pg_stat_database update stats_reset only by pg_stat_reset

From: 张连壮 <lianzhuangzhang(at)gmail(dot)com>
To: Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com>
Cc: Michael Paquier <michael(at)paquier(dot)xyz>, Daniel Verite <daniel(at)manitou-mail(dot)org>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: pg_stat_database update stats_reset only by pg_stat_reset
Date: 2019-07-17 05:52:46
Message-ID: CALerpYq-WR9DsubuW-zwjQfXJZCdOjWnDKkHFOgfGzzRSkNifg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Yeah, I agree. this is not necessary, i will remove the commitfest at
'2019-07-19'.

Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)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
>
>

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Amit Kapila 2019-07-17 06:12:52 Re: POC: Cleaning up orphaned files using undo logs
Previous Message Marko Tiikkaja 2019-07-17 05:52:06 Re: [PATCH] Implement INSERT SET syntax