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
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 |