Re: [PATCH] dtrace probes for memory manager
От | Frank Ch. Eigler |
---|---|
Тема | Re: [PATCH] dtrace probes for memory manager |
Дата | |
Msg-id | 20091210213440.GB32064@redhat.com обсуждение исходный текст |
Ответ на | Re: [PATCH] dtrace probes for memory manager (Zdenek Kotala <Zdenek.Kotala@Sun.COM>) |
Список | pgsql-hackers |
Hi - On Thu, Dec 10, 2009 at 09:33:28PM +0100, Zdenek Kotala wrote: > [...] > > If the dormant overhead of these probes is measured or suspected to be > > excessive, consider using the dtrace-generated per-probe foo_ENABLED() > > conditional, or a postgres configuration global thusly: > [...] foo_enable() is good to use when number of argument and their > evaluation cost too much. In this case it does no seem to be much > useful. [...] Right, I just wanted to make the others aware of the option. > > if (__builtin_expect(TRACE_POSTGRESQL_MCXT_ALLOC_ENABLED(), 0)) > > TRACE_POSTGRESQL_MCXT_ALLOC(...); > > > > so that the whole instrumentation parameter setup/call can be placed > > out of the hot line with gcc -freorder-blocks. > > compiler specific construct is not good way. Do not forget that also > other compiler exists. Certainly. Many projects -- but apparently not postgresql -- wrap such branch prediction hints in macros such as likely() and unlikely(), which are easily no-op'd for compilers that don't support this sort of thing. - FChE
В списке pgsql-hackers по дате отправления: