Re: RFC: replace pg_stat_activity.waiting with something more descriptive

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>
Cc: Andres Freund <andres(at)anarazel(dot)de>, Merlin Moncure <mmoncure(at)gmail(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: RFC: replace pg_stat_activity.waiting with something more descriptive
Date: 2015-06-26 12:56:55
Message-ID: CA+Tgmoaenh_fzT=8VnODWX569X+mU_LgkZ2XOuNgH=i1MCm_tA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Jun 25, 2015 at 11:57 PM, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
>> >> 3. Add new view 'pg_stat_wait_event' with following info:
>> >> pid - process id of this backend
>> >> waiting - true for any form of wait, false otherwise
>> >> wait_event_type - Heavy Weight Lock, Light Weight Lock, I/O wait, etc
>> >> wait_event - Lock (Relation), Lock (Relation Extension), etc
>> I am pretty unconvinced that it's a good idea to try to split up the
>> wait event into two columns. I'm only proposing ~20 wait states, so
>> there's something like 5 bits of information here. Spreading that
>> over two text columns is a lot, and note that Amit's text would
>> basically recapitulate the contents of the first column in the second
>> one, which I cannot get excited about.
> There is an advantage in splitting the columns which is if wait_event_type
> column indicates Heavy Weight Lock, then user can go and check further
> details in pg_locks, I think he can do that even by seeing wait_event
> column, but that might not be as straightforward as with wait_event_type
> column.

It's just a matter of writing event_type LIKE 'Lock %' instead of
event_type = 'Lock'.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Paquier 2015-06-26 13:03:05 Nitpicking: unnecessary NULL-pointer check in pg_upgrade's controldata.c
Previous Message Robert Haas 2015-06-26 12:40:35 Re: Redesigning checkpoint_segments