> On Jan 25, 2025, at 2:42 PM, frits.hoogl...@gmail.com wrote: > > One thing I found is that because certain statistics are provided after a > query has run, measuring them in a fine grained way shows a peak for > something that in reality is taking place over a period of time.
+1 I have also encountered this. I think most stats (pg_stat_statements, block hit/read counts, object access counts, etc) are all updated at query completion time. I think it’s related to the architecture of the statistics collector. The main thing I’ve seen change in real time is fields in pg_stat_activity (like wait events). As a result, I’m not sure how useful per-second stats on the other views are. Mainly I think it will just tell you which second the query completed, and that’s easy to get from logging (db or app tier). stats from the other views tend to be most useful when normalized over minutes or hours. I wrote out a Postgres observability wishlist two weeks ago and much of it would probably best be added to pg_stat_activity [1]. I wonder if we might eventually want the underlying pg_stat_activity function to have an argument to exclude pulling data that’s less frequently accessed, similar to how the pg_stat_statements function can exclude query text to be more efficient. -Jeremy 1: https://ardentperf.com/2025/01/08/postgres-per-connection-statistics/
