Re: Proposed changes to DTrace probe implementation - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Proposed changes to DTrace probe implementation
Date
Msg-id 8904.1204064062@sss.pgh.pa.us
Whole thread Raw
In response to Re: Proposed changes to DTrace probe implementation  (Robert Lor <Robert.Lor@Sun.COM>)
Responses Re: Proposed changes to DTrace probe implementation
List pgsql-hackers
Robert Lor <Robert.Lor@Sun.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


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Required make version
Next
From: Tom Lane
Date:
Subject: Re: pg_dump additional options for performance