From: | Robert Lor <Robert(dot)Lor(at)Sun(dot)COM> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-hackers list <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Proposed changes to DTrace probe implementation |
Date: | 2008-02-26 19:45:04 |
Message-ID: | 47C46C40.9000907@sun.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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.
> Possibly I have a different view of the uses of dtrace than you do, but
> most of the events I'd be interested in probing are probably pretty
> Postgres-specific.
I agree that most probes, especially low level ones, will be Postgres
specific.
> I think distinguishing half a dozen of them on the
> assumption that there should be (exact) matches to that probe point in
> most databases is misleading and a source of useless extra notation.
>
>
This is just forward looking on my part since other OS databases will
most likely be adding Dtrace probes as well. I'll put them back
together in one provider for now!
Regards,
-Robert
From | Date | Subject | |
---|---|---|---|
Next Message | Joshua D. Drake | 2008-02-26 19:47:55 | Re: pg_dump additional options for performance |
Previous Message | Simon Riggs | 2008-02-26 19:34:16 | Re: pg_dump additional options for performance |