On Wed, Jun 8, 2016 at 10:11 AM, Michael Paquier <michael.paqu...@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
wait-event-set-v2.patch
Description: application/download
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
