Re: pgbench - use pg logging capabilities
От | Fabien COELHO |
---|---|
Тема | Re: pgbench - use pg logging capabilities |
Дата | |
Msg-id | alpine.DEB.2.21.2001100659560.5474@pseudo обсуждение исходный текст |
Ответ на | Re: pgbench - use pg logging capabilities (Michael Paquier <michael@paquier.xyz>) |
Ответы |
Re: pgbench - use pg logging capabilities
|
Список | pgsql-hackers |
Bonjour Michaël, >> TBH, my recommendation would be to drop *all* of these likely() >> and unlikely() calls. What evidence have you got that those are >> meaningfully improving the quality of the generated code? And if >> they're buried inside macros, they certainly aren't doing anything >> useful in terms of documenting the code. > > Yes. I am wondering if we should not rework this part of the logging > with something like the attached. My 2c, thoughts welcome. ISTM that the intent is to minimise the performance impact of ignored pg_log calls, especially when under debug where it is most likely to be the case AND that they may be in critical places. Compared to dealing with the level inside the call, the use of the level variable avoids a call-test-return cycle in this case, and the unlikely should help the compiler reorder instructions so that no actual branch is taken under the common case. So I think that the current situation is a good thing at least for debug. For other levels, they are on by default AND would not be placed at critical performance points, so the whole effort of avoiding the call are moot. I agree with Tom that __pg_log_level variable name violates usages. ISTM that switching the variable to explicitely global solves the issues, and that possible the level test can be moved to inside the function for all but the debug level. See attached which reprises some of your idea, but keep the outside filtering for the debug level. -- Fabien.
Вложения
В списке pgsql-hackers по дате отправления: