From: | Michael Paquier <michael(dot)paquier(at)gmail(dot)com> |
---|---|
To: | Craig Ringer <craig(at)2ndquadrant(dot)com> |
Cc: | Kevin Grittner <kgrittn(at)gmail(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com>, Alexander Korotkov <a(dot)korotkov(at)postgrespro(dot)ru>, PostgreSQL mailing lists <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: exposing wait events for non-backends (was: Tracking wait event for latches) |
Date: | 2016-12-13 01:13:17 |
Message-ID: | CAB7nPqQPWcFrCnNazwtOBTmVwDANRanB3iKo_dfY-eCu7bz_ig@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, Dec 13, 2016 at 10:05 AM, Craig Ringer <craig(at)2ndquadrant(dot)com> wrote:
> We should probably expose a proc_type or something, with types:
>
> * client_backend
> * bgworker
> * walsender
> * autovacuum
> * checkpointer
> * bgwriter
A text field is adapted then, more than a single character.
> for simpler filtering.
>
> I don't think existing user code is likely to get upset by more
> processes appearing in pg_stat_activity, and it'll be very handy.
Indeed, for WAL senders now abusing of the query field is definitely
not consistent. Even if having this information is useful, adding such
a column would make sense. Still, one thing that is important to keep
with pg_stat_activity is the ability to count the number of
connections that are part of max_connections for monitoring purposes.
The docs definitely would need an example of such a query counting
only client_backend and WAL senders and tell users that this can be
used to count how many active connections there are.
--
Michael
From | Date | Subject | |
---|---|---|---|
Next Message | Amit Langote | 2016-12-13 01:17:30 | Re: Declarative partitioning - another take |
Previous Message | Dilip Kumar | 2016-12-13 01:12:40 | Re: Proposal : Parallel Merge Join |