From: | Michael Paquier <michael(at)paquier(dot)xyz> |
---|---|
To: | Greg Sabino Mullane <htamfids(at)gmail(dot)com> |
Cc: | zhouenbing <zhouenbing(at)sunwoda-evb(dot)com>, pgsql-bugs(at)lists(dot)postgresql(dot)org |
Subject: | Re: empty,query_id, pg_stat_activity |
Date: | 2025-09-04 00:25:00 |
Message-ID: | aLjcXPixsn8XltZv@paquier.xyz |
Views: | Whole Thread | Raw Message | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
On Wed, Sep 03, 2025 at 04:54:27PM -0400, Greg Sabino Mullane wrote:
> The session is active, but there is no I/O yet, as the query has arrived,
> but has not been parsed yet. The queryid appears right before the query
> actually executes, so a lack of queryid is a safe indicator that the query
> is not actually doing any work yet- it's still spinning up. From a
> performance monitoring standpoint, you should be safe to exclude rows with
> no queryid.
Yeah, and there's likely no point in feeding the data of
pg_stat_activity to a CTAS, something that pg_stat_statements does for
most people these days.
FWIW, I use queries based on pg_stat_activity for monitoring purposes
in benchmarks to get aggregated values about wait events, to be able
to grab patterns, most of the time. Filtering out query IDs would
lead to less information gathered. You did not mention why
pg_stat_activity coupled with a query ID would be useful for you,
especially since we have a bunch of pgstats views that are able to get
aggregated data for the user, as well, to grab for bottlenecks, like
pg_stat_io, etc.
--
Michael
From | Date | Subject | |
---|---|---|---|
Next Message | zhouenbing | 2025-09-04 03:32:18 | 答复: empty,query_id, pg_stat_activity |
Previous Message | Greg Sabino Mullane | 2025-09-03 20:58:08 | Re: BUG #19042: Option --help not recognized at the end of command line in pg_restore |