Re: Adding locks statistics
| От | Michael Paquier |
|---|---|
| Тема | Re: Adding locks statistics |
| Дата | |
| Msg-id | abpfH33mR4Mp9dtO@paquier.xyz обсуждение исходный текст |
| Ответ на | Re: Adding locks statistics (Bertrand Drouvot <bertranddrouvot.pg@gmail.com>) |
| Ответы |
Re: Adding locks statistics
|
| Список | pgsql-hackers |
On Wed, Mar 18, 2026 at 04:36:04AM +0000, Bertrand Drouvot wrote: >> So, we're back to what we were discussing before the split. As in v7, 0003 is >> adding the new GUC. So that we can see what having a new GUC implies in ProcSleep() >> and we can just get rid of 0003 if we think the GUC is not worth the extra complexity >> (I don't have a strong opinion on it but tempted to think that the extra GUC is >> not worth it). > > PFA, a rebase due to fd6ecbfa75ff. Looking again at this patch, all the fields that you are adding are in non-critical paths, so it looks fine by me to begin with this data set. We may want to document that for future readers of the code to not add counter increments in the fast code paths, where performance could matter. Let's also drop 0003 with the GUC. log_lock_waits is enabled by default and we are in a wait path which would not be performance-critical. Regarding the isolation test, the new permutations add 4 pg_sleep() calls at 500ms each, making the stats test longer. It also looks like the outputs are the same for the two alternate expected files? Do you think that it could be possible to move these tests to a new file, perhaps cutting a bit the sleeps to make it faster? -- Michael
Вложения
В списке pgsql-hackers по дате отправления: