Re: [PATCH] dtrace probes for memory manager

From: "Joshua D(dot) Drake" <jd(at)commandprompt(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Zdenek Kotala <Zdenek(dot)Kotala(at)Sun(dot)COM>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [PATCH] dtrace probes for memory manager
Date: 2009-11-13 21:09:06
Message-ID: 1258146546.14849.359.camel@jd-desktop.unknown.charter.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, 2009-11-13 at 16:06 -0500, Tom Lane wrote:
> Zdenek Kotala <Zdenek(dot)Kotala(at)Sun(dot)COM> writes:
> > Attached patch contains new dtrace probes for memory management.
>
> This is a bad idea and I want to reject it outright. No ordinary user
> is really going to care about those details, and palloc is a
> sufficiently hot hot-spot that even the allegedly negligible overhead
> of an inactive dtrace probe is going to cost us.

No ordinary user is going to use dtrace at all.

>
> If this goes in, I will disable dtrace support in Red Hat's builds,
> and I rather imagine that other packagers will react similarly.

Is it possible to have a set of probes that would only be enabled with
say, --enable-debug compile time option? I could certainly see the
benefit to these probes for profiling but that is such as specific use
that it seems to need a specific flag anyway.

Sincerely,

Joshua D. Drake

>
> regards, tom lane
>

--
PostgreSQL.org Major Contributor
Command Prompt, Inc: http://www.commandprompt.com/ - 503.667.4564
Consulting, Training, Support, Custom Development, Engineering
If the world pushes look it in the eye and GRR. Then push back harder. - Salamander

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andrew Dunstan 2009-11-13 21:09:46 Re: Experimental patch: generating BKI revisited
Previous Message Simon Riggs 2009-11-13 21:07:24 Re: next CommitFest