> As it looks like we have a consensus that reducing the number of interrupts > also > makes sense, I just provided a rebase version of the 1 Hz version (see [0], > that > also makes clear in the doc that the new field might show slightly old > values).
That makes sense. However, I suspect the "1 Hz" work code will no longer be needed if CF entry 5118 [1] mentioned by Thomas [2] a few days back goes through. Maybe this extra work can be removed if [1] goes through. What do you think? With regards to CF 5118 and what it means to the current discussion, below are my thoughts. I tested with both CF 5118 [1] and the cost-delay tracking patch. With that in place, pg_usleep is able to sleep the full requested, as mentioned by Thomas [3]. This is because certain interrupts like Parallel Message and others are not signaled by SIGUSR1 any longer, but with latches. >From this discussion, there is desire for a sleep function that: 1/ Sleeps for the full duration of the requested time 2/ Continues to handle important interrupts during the sleep While something like CF 5118 will take care of point #1, it will not deal with #2. Also, the v11 [4] patch does not do #2 either. So I think in the sleep loop, we need a C_F_I call. The same type of loop can also be used to call WaitForSingleObject. If CF 5118 gets committed, will still need similar loop that calls C_F_I, but the function will need to call WaitLatchUs [5]. Thoughts? -- Sami [1] https://commitfest.postgresql.org/49/5118/ [2] https://www.postgresql.org/message-id/CA%2BhUKG%2Bf-nEc_SowDLW1JMUa6Of5sCK-JZ%3Dv-KhL1xgXk83fiw%40mail.gmail.com [3] https://www.postgresql.org/message-id/CA%2BhUKGKpo3fM%3DrnfdxHqt%2BjNGh_zUNcL1ob4hMsb%3DjFfKn9Aag%40mail.gmail.com [4] https://www.postgresql.org/message-id/e3297b5e-0b33-4f45-afcd-4b00ba0b3547%40gmail.com [5] https://www.postgresql.org/message-id/CA+hUKGKVbJE59JkwnUj5XMY+-rzcTFciV9vVC7i=lufwpds...@mail.gmail.com
