Re: Frontend error logging style
От | Peter Eisentraut |
---|---|
Тема | Re: Frontend error logging style |
Дата | |
Msg-id | c1d2b11d-d7e2-aafc-4bab-bb41b5f3b5ff@enterprisedb.com обсуждение исходный текст |
Ответ на | Re: Frontend error logging style (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Frontend error logging style
|
Список | pgsql-hackers |
On 08.04.22 22:26, Tom Lane wrote: > I wrote: >> One other loose end is bothering me: I stuck with logging.h's >> original choice to put "if (likely())" or "if (unlikely())" >> conditionals into the macros, but I rather suspect that that's >> just a waste. I think we should put a centralized level check >> into logging.c, and get rid of at least the "if (likely())" >> checks, because those are going to succeed approximately 100.0% >> of the time. Maybe there's an argument for keeping the unlikely() >> ones. > > Concretely, something like the attached. As a simple check, > I looked at the compiled size of pg_dump. It went from > > text data bss dec hex filename > 380298 4008 1384 385690 5e29a /home/postgres/testversion/bin/pg_dump > > to > > text data bss dec hex filename > 374954 4008 1384 380346 5cdba src/bin/pg_dump/pg_dump > > for a savings of about 5K or 1.5%. Not a huge amount, but > not nothing either, especially considering that the existing > coding isn't buying us anything. Yeah, that seems ok to change. The previous coding style is more useful if you have a lot of debug messages in a hot code path, but that usually doesn't apply to where this is used.
В списке pgsql-hackers по дате отправления: