Re: Sampling profiler updated

Поиск
Список
Период
Сортировка
От Itagaki Takahiro
Тема Re: Sampling profiler updated
Дата
Msg-id 20090722093930.A05A.52131E4D@oss.ntt.co.jp
обсуждение исходный текст
Ответ на Re: Sampling profiler updated  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы trace hooks (for 2nd commitfest)
Список pgsql-hackers
Tom Lane <tgl@sss.pgh.pa.us> wrote:

> For the record, I think this patch is a waste of manpower and we should
> rely on dtrace/systemtap.  However, if we are going to make our own
> homegrown substitute for those facilities, a minimum requirement should
> be that it uses the dtrace macros already put into the sources, rather
> than expecting that it gets to clutter the code some more with its own
> set of tracing markers.

How about export dtrace functions as hook function pointers?
For example:
   void (*LWLOCK_WAIT_START_hook)(int, int);   #define TRACE_POSTGRESQL_LWLOCK_WAIT_START(INT1, INT2) \       if
(LWLOCK_WAIT_START_hook== NULL); else \           LWLOCK_WAIT_START_hook(INT1, INT2)   #define
TRACE_POSTGRESQL_LWLOCK_WAIT_START_ENABLED()\       (LWLOCK_WAIT_START_hook != NULL)
 

If there were such hooks, my profiler could be implemented as
a loadable module on top of the hooks. It might be good to initialize
LWLOCK_WAIT_START_hook with lwlock__wait__start(). If do so, dtrace
probes still work and we can avoid if-null checks for each call.

If acceptable, I'll also suggest new probe functions like
SLEEP, SEND, RECV, SPINLOCK_FAILURE and so on.

Regards,
---
ITAGAKI Takahiro
NTT Open Source Software Center




В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Modifying TOAST_TUPLE_THRESHOLD and TOAST_TUPLE_TARGET?
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Higher TOAST compression.