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

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Michael Paquier <michael(dot)paquier(at)gmail(dot)com>
Cc: Thomas Reiss <thomas(dot)reiss(at)dalibo(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: 2016-03-17 14:10:25
Message-ID: CA+TgmoY5FT689NC_scDt07S8x9vYbzTZWTfUV-wfjGypu=8+QA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Mar 16, 2016 at 10:03 PM, Michael Paquier
<michael(dot)paquier(at)gmail(dot)com> wrote:
> On Wed, Mar 16, 2016 at 5:28 AM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>> On Tue, Mar 15, 2016 at 9:17 AM, Thomas Reiss <thomas(dot)reiss(at)dalibo(dot)com> wrote:
>>> Here's a small docpatch to fix two typos in the new documentation.
>>
>> Thanks, committed.
>
> I just had a quick look at the wait_event committed, and I got a
> little bit disappointed that we actually do not track latch waits yet,
> which is perhaps not that useful actually as long as an event name is
> not associated to a given latch wait when calling WaitLatch. I am not
> asking for that with this release, this is just for the archive's
> sake, and I don't mind coding that myself anyway if need be. The
> LWLock tracking facility looks rather cool btw :)

Yes, I'm quite excited about this. I think it's pretty darn awesome.

I doubt that it would be useful to treat a latch wait as an event.
It's too generic. You'd want something more specific, like waiting
for WAL to arrive or waiting for a tuple from a parallel worker or
waiting to write to the client. It'll take some thought to figure out
how to organize and categorize that stuff, but it'll also be wicked
cool.

--
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 Andres Freund 2016-03-17 14:53:26 Re: Performance degradation in commit ac1d794
Previous Message Michael Paquier 2016-03-17 14:05:42 Re: silent data loss with ext4 / all current versions