Re: empty,query_id, pg_stat_activity

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

In response to

Responses

Browse pgsql-bugs by date

  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