| From: | Theo Schlossnagle <jesus(at)omniti(dot)com> |
|---|---|
| To: | Mark Kirkwood <markir(at)paradise(dot)net(dot)nz> |
| Cc: | Theo Schlossnagle <jesus(at)omniti(dot)com>, "Jim C(dot) Nasby" <jnasby(at)pervasive(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Robert Lor <Robert(dot)Lor(at)Sun(dot)COM>, pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: Generic Monitoring Framework Proposal |
| Date: | 2006-06-19 23:48:55 |
| Message-ID: | F8550E6D-8CB6-4F98-AC32-32758151543D@omniti.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Jun 19, 2006, at 7:39 PM, Mark Kirkwood wrote:
> We will need to benchmark on FreeBSD to see if those comments about
> overhead stand up to scrutiny there too.
I've followed the development of DTrace on FreeBSD and the design
approach is mostly identical to the Solaris one. This would mean
that if there is overhead on FreeBSD not present on Solaris it would
be considered a big and likely fixed.
> I would think that even if (for instance) we find that there is no
> overhead on Solaris, those of us on platforms where DTrace is less
> mature would want the option of building without any probes at all
> in the code - I guess a configure option "--without-dtrace" on by
> default on those platforms would do it.
Absolutely. As they are all proposed as preprocessor macros, this
would be trivial to accomplish.
// Theo Schlossnagle
// CTO -- http://www.omniti.com/~jesus/
// OmniTI Computer Consulting, Inc. -- http://www.omniti.com/
// Ecelerity: Run with it.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2006-06-20 01:35:30 | Re: sync_file_range() |
| Previous Message | Mark Kirkwood | 2006-06-19 23:39:35 | Re: Generic Monitoring Framework Proposal |