GitHub user leborchuk added a comment to the discussion: [Ideas] Add instrumentation and latency metrics to the Anser subsystem
> For the `anser.stats()` / `stats_reset()` contract, could each snapshot > identify its reset generation, and could the API document how a reader knows > a reset has completed? A consumer computing interval rates from cumulative > counters needs to distinguish two reads that straddle a reset. Checking for a > negative delta alone can miss the reset if enough new activity has already > exceeded the previous count. > > This also affects interval histogram quantiles: subtract corresponding bucket > counts only across compatible snapshots from one reset generation, then > derive an approximate quantile from that interval distribution; subtracting > the displayed p99 values would not give an interval p99. Given the > no-new-locks constraint, stating whether count, total time and bucket reads > are a best-effort snapshot would help consumers avoid asserting exact > consistency during concurrent updates. > > This is feedback on the proposed API, not a reproduced implementation issue. > Disclosure: I build Telemetry; this reply was drafted with AI assistance. Yes, thank you. It is quite important. If we want to add a stat() method, there should be a `stats_reset()' method and the time when the reset was performed. I remember a multi-year discussion among pg-hackers about adding a reset time to pg_stat_statements. Luckily, it finally got merged ) GitHub link: https://github.com/apache/cloudberry/discussions/1958#discussioncomment-18333486 ---- This is an automatically sent email for [email protected]. To unsubscribe, please send an email to: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
