Re: Proposed changes to DTrace probe implementation

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Robert Lor <Robert(dot)Lor(at)Sun(dot)COM>
Cc: pgsql-hackers list <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Proposed changes to DTrace probe implementation
Date: 2008-02-26 22:14:22
Message-ID: 8904.1204064062@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Robert Lor <Robert(dot)Lor(at)Sun(dot)COM> writes:
> Tom Lane wrote:
>> I'm unimpressed; it's not at all clear that you'd be measuring quite the
>> same thing in, say, mysql as in postgres.

> I think it depends on the probe, but for transaction rates like start or
> commit, don't you think it's pretty black & white as long as the probes
> are placed in the correct locations.

I'm not so sure. For instance, from what I understand about mysql
(admittedly not a lot) their notion of transaction is rather
storage-engine-specific. It wouldn't be hard to come up with situations
where they show many more or fewer "transactions" than we do.

The concern I've got about this is basically that it would encourage
plastering the same label on subtly different counts, leading to
confusion and perhaps mistaken conclusions. I would prefer to see any
common probes be reverse-engineered *after the fact*, ie, after you've
already instrumented several DB's you're in a better position to figure
out what's common and what's not. I distrust preconceived notions about
that.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2008-02-26 22:36:29 Re: pg_dump additional options for performance
Previous Message Tom Lane 2008-02-26 22:03:53 Re: Required make version