Re: Tracking wait event for latches
От | Robert Haas |
---|---|
Тема | Re: Tracking wait event for latches |
Дата | |
Msg-id | CA+TgmoZiXtgayMcPtq6-D4TPbWCeQeQ2QW5bd+YXgDRDRFNANg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Tracking wait event for latches (Thomas Munro <thomas.munro@enterprisedb.com>) |
Ответы |
Re: Tracking wait event for latches
Re: Tracking wait event for latches |
Список | pgsql-hackers |
On Tue, Sep 20, 2016 at 7:13 PM, Thomas Munro <thomas.munro@enterprisedb.com> wrote: > This paragraph seems a bit confused. I suggest something more like > this: "The server process is waiting for one or more sockets, a timer > or an interprocess latch. The wait happens in a WaitEventSet, > <productname>PostgreSQL</>'s portable IO multiplexing abstraction." I'm worried we're exposing an awful lot of internal detail here. Moreover, it's pretty confusing that we have this general concept of wait events in pg_stat_activity, and then here the specific type of wait event we're waiting for is the ... wait event kind. Uh, what? 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. The "SecureRead" and "SecureWrite" wait events are going to be confusing, because the connection isn't necessarily secure. I think those should be called "ClientRead" and "ClientWrite". Comprehensibility is more important than absolute consistency with the C function names. 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. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления: