public inbox for [email protected]  

help / color / mirror / Atom feed

From: Jeremy Schneider <[email protected]>
To: [email protected]
Cc: peter plachta <[email protected]>
Cc: Pavel Stehule <[email protected]>
Cc: [email protected]
Subject: Re: Any risk or overhead considerations for frequently executing queries against catalog tables?
Date: Sun, 26 Jan 2025 09:56:47 -0800
Message-ID: <[email protected]> (raw)
In-Reply-To: <[email protected]>
References: <[email protected]>


> On Jan 25, 2025, at 2:42 PM, [email protected] 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/

view thread (9+ messages)

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: [email protected]
  Cc: [email protected], [email protected], [email protected], [email protected], [email protected]
  Subject: Re: Any risk or overhead considerations for frequently executing queries against catalog tables?
  In-Reply-To: <[email protected]>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox