Re: Expose lock group leader pid in pg_stat_activity

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: Re: Expose lock group leader pid in pg_stat_activity
Date: 2019-12-25 18:32:09
Message-ID: CAOBaU_bMpBZOJ_aC1_iJ5h=U9z=Om=TPBDyYbKrw1SyF_+NLmg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Dec 25, 2019 at 7:03 PM Julien Rouhaud <rjuju123(at)gmail(dot)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 Content-Type Size
pgsa_leader_pid-v2.diff text/x-patch 8.8 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2019-12-25 20:45:47 Re: unsupportable composite type partition keys
Previous Message Tom Lane 2019-12-25 18:21:31 Re: unsupportable composite type partition keys