Re: Tracking wait event for latches

On Wed, Sep 21, 2016 at 10:02 AM, Michael Paquier
<michael(dot)paquier(at)gmail(dot)com> wrote:
> On Wed, Sep 21, 2016 at 10:23 PM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>> I have to admit that I like the individual event names quite a bit,
>> and I think the detail will be useful to users. But I wonder if
>> there's a better way to describe the class of events that we're
>> talking about that's not so dependent on internal data structures.
>> Maybe we could divide these waits into a couple of categories - e.g.
>> "Socket", "Timeout", "Process" - and then divide these detailed wait
>> events among those classes.
>
> pgstat.h is mentioning that there is 1 byte still free. I did not
> notice that until a couple of minutes ago. There are 2 bytes used for
> the event ID, and 1 byte for the class ID, but there are 4 bytes
> available. Perhaps we could use this extra byte to store this extra
> status information, then use it for WaitEventSet to build up a string
> that will be stored in classId field? For example if a process is
> waiting on a socket and a timeout, we'd write "Socket,Timeout" as a
> text field.

No, that's not what I want to do. I think we should categorize the
events administratively by their main purpose, rather than
technologically by what we're waiting for.

>> Another thing to think about is that there's no way to actually see
>> wait event information for a number of the processes which this patch
>> instruments, because they don't appear in pg_stat_activity.
>
> We could create a new system to track the activity of system-related
> processes, for example pg_stat_system_activity, or pg_system_activity,
> and list all the processes that are not counted in max_connections...

Yes. Or we could decide to include everything in pg_stat_activity. I
think those are the two reasonable options.

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