Re: Tracking wait event for latches

On Wed, Jun 8, 2016 at 10:11 AM, Michael Paquier
<michael.paquier@gmail.com> wrote:
> Yeah, that's as well my line of thoughts on the matter since the
> beginning: keep it simple and done. What is written just after those
> words is purely hand-waving and I have no way to prove it, but my
> instinctive guess is that more than 90% of the real use cases where we
> need to track the latch waits in pgstat would be covered without the
> need of this extra shared memory infrastructure for extensions.

So, I have done some extra tests with my patch to see if I move the
event reporting down to WaitEventSetWait and see what is the effect on
secure_read and secure_write. And the conclusion is that I am seeing
no difference, so I changed the patch to the way suggested by Thomas.
In this test, what I have done was using the following pgbench script
with -C via an SSL connection:
\set id random(1,1000)
As the script file is not empty, a connection to the server is opened,
so this goes though secure_read at minimal cost on the backend.

Also, I have change the event ID notation as follows to be consistent
with the routine names:
WAL -> Wal
PG -> Pg
I also found that LATCH_RECOVERY_WAL_ALL was reporting
"XLogAfterAvailable" as name, which was incorrect.

Finally, I have changed the patch so as it does not track "Latch"
events, but "EventSet" events instead, per the suggestion of Thomas.
"WaitEventSet" is too close to wait_event in my taste so I shortened
the suggeston. There were also some conflicts caused by the recent
commit 887feefe, which are fixed.

Attached is an updated patch.
--
Michael