Re: Proposed changes to DTrace probe implementation

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Proposed changes to DTrace probe implementation
Дата
Msg-id 8904.1204064062@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Proposed changes to DTrace probe implementation  (Robert Lor <Robert.Lor@Sun.COM>)
Ответы Re: Proposed changes to DTrace probe implementation  (Robert Lor <Robert.Lor@Sun.COM>)
Список 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 по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Required make version
Следующее
От: Tom Lane
Дата:
Сообщение: Re: pg_dump additional options for performance