Re: Expose lock group leader pid in pg_stat_activity
От | Julien Rouhaud |
---|---|
Тема | Re: Expose lock group leader pid in pg_stat_activity |
Дата | |
Msg-id | CAOBaU_bMpBZOJ_aC1_iJ5h=U9z=Om=TPBDyYbKrw1SyF_+NLmg@mail.gmail.com обсуждение исходный текст |
Ответ на | Expose lock group leader pid in pg_stat_activity (Julien Rouhaud <rjuju123@gmail.com>) |
Ответы |
Re: Expose lock group leader pid in pg_stat_activity
|
Список | pgsql-hackers |
On Wed, Dec 25, 2019 at 7:03 PM Julien Rouhaud <rjuju123@gmail.com> wrote: > > 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 And I just realized that I forgot to update rule.out, sorry about that. v2 attached.
Вложения
В списке pgsql-hackers по дате отправления: