On Wed, Sep 21, 2016 at 10:02 AM, Michael Paquier <michael.paqu...@gmail.com> wrote: > On Wed, Sep 21, 2016 at 10:23 PM, Robert Haas <robertmh...@gmail.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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
