Re: [PATCH] dtrace probes for memory manager
От | Zdenek Kotala |
---|---|
Тема | Re: [PATCH] dtrace probes for memory manager |
Дата | |
Msg-id | 1260562071.2642.68.camel@localhost обсуждение исходный текст |
Ответ на | Re: [PATCH] dtrace probes for memory manager (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: [PATCH] dtrace probes for memory manager
|
Список | pgsql-hackers |
Tom Lane píše v pá 11. 12. 2009 v 14:38 -0500: > Robert Haas <robertmhaas@gmail.com> writes: > > I thought we had an idea of using the AllocSet dispatch mechanism to > > make this zero-overhead in the case where the probes are not enabled. > > What happened to that notion? > > I must have missed that discussion, but +1 --- should be possible to get > to zero-overhead-when-off that way. The trick is to figure out > what/where enables the alternate implementation. The current design > assumes that the callers of FooContextCreate choose the implementation, > but we don't want that here. I thought about it. I think we can use GUC variable (e.g. dtraced_alloc) and hook switch pointers to dtraced AsetFunctions. The problem is how to distribute to all backend. Zdenek
В списке pgsql-hackers по дате отправления: