From: | Julien Rouhaud <rjuju123(at)gmail(dot)com> |
---|---|
To: | PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Cc: | Guillaume Lelarge gleu <guillaume(at)lelarge(dot)info> |
Subject: | Expose lock group leader pid in pg_stat_activity |
Date: | 2019-12-25 18:03:44 |
Message-ID: | CAOBaU_Yy5bt0vTPZ2_LUM6cUcGeqmYNoJ8-Rgto+c2+w3defYA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hello,
Guillaume (in Cc) recently pointed out [1] that it's currently not
possible to retrieve the list of parallel workers for a given backend
at the SQL level. His use case was to develop a function in plpgsql
to sample a given query wait event, but it's not hard to imagine other
useful use cases for this information, for instance doing some
analysis on the average number of workers per parallel query, or ratio
of parallel queries. IIUC parallel queries is for now the only user
of lock group, so this should work just fine.
I'm attaching a trivial patch to expose the group leader pid if any
in pg_stat_activity. Quick example of usage:
=# SELECT query, leader_pid,
array_agg(pid) filter(WHERE leader_pid != pid) AS members
FROM pg_stat_activity
WHERE leader_pid IS NOT NULL
GROUP BY query, leader_pid;
query | leader_pid | members
-------------------+------------+---------------
select * from t1; | 28701 | {28728,28732}
(1 row)
[1] https://twitter.com/g_lelarge/status/1209486212190343168
Attachment | Content-Type | Size |
---|---|---|
pgsa_leader_pid-v1.diff | text/x-patch | 4.0 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2019-12-25 18:21:31 | Re: unsupportable composite type partition keys |
Previous Message | Alexey Kondratov | 2019-12-25 17:28:04 | Re: Physical replication slot advance is not persistent |