Re: Expose lock group leader pid in pg_stat_activity - Mailing list pgsql-hackers

From Julien Rouhaud
Subject Re: Expose lock group leader pid in pg_stat_activity
Date
Msg-id CAOBaU_bMpBZOJ_aC1_iJ5h=U9z=Om=TPBDyYbKrw1SyF_+NLmg@mail.gmail.com
Whole thread Raw
In response to Expose lock group leader pid in pg_stat_activity  (Julien Rouhaud <rjuju123@gmail.com>)
Responses Re: Expose lock group leader pid in pg_stat_activity
List 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.

Attachment

pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: unsupportable composite type partition keys
Next
From: Tom Lane
Date:
Subject: Re: unsupportable composite type partition keys