Re: [patch] executor and slru dtrace probes

From: Theo Schlossnagle <jesus(at)omniti(dot)com>
To: Zdenek Kotala <Zdenek(dot)Kotala(at)sun(dot)com>
Cc: Theo Schlossnagle <jesus(at)omniti(dot)com>, Bernd Helmle <mailings(at)oopsware(dot)de>, pgsql-hackers(at)postgresql(dot)org, Robert(dot)Lor(at)Sun(dot)COM
Subject: Re: [patch] executor and slru dtrace probes
Date: 2009-12-10 00:08:07
Message-ID: AD638303-5375-4F02-84F9-5DC938FF37AF@omniti.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


On Dec 8, 2009, at 5:10 AM, Zdenek Kotala wrote:

> Dne 8.12.09 00:27, Bernd Helmle napsal(a):
>> --On 13. November 2009 23:29:41 +0100 Zdenek Kotala <Zdenek(dot)Kotala(at)Sun(dot)COM> wrote:
>>> t contains two DTrace probe groups. One is related to monitoring SLRU
>>> and second is about executor nodes.
>>>
>>> I merged it with the head.
>>>
>>> Original end of mail thread is here:
>>>
>>> http://archives.postgresql.org/pgsql-hackers/2009-04/msg00148.php
>> I've started to review this.
>> It seems to me the attached patch wasn't adjusted or discussed again to address Tom's complaints? At least the executor probes contained here hold still the same issues mentioned by Tom in the discussion linked here.
>
> I did not make any change. I only revival patch and merge it with head. I think that SLRU probes are OK and acceptable.
>
> Tom's issues with executor probes are still there and I expect discussion about them. IIRC Theo uses these probes in production.
>
> If you think that it is better I could split patch into two separate patches and both can be reviewed separately.

I suppose I see it as a simple thing. The probes have no performance impact when they are not instrumented. I've used them on rare occasion to understand which exec nodes are causing which disk accesses. Seemed pretty darn useful at the time. There is (of course) some performance overhead when they are enabled, but that is intentionally performed by the operator, so it seems like a non-issue.

Now, there was some indication that there was a better place to probe that would be more comprehensive -- that should be addressed.

--
Theo Schlossnagle
Esoteric Curio -- http://lethargy.org/
OmniTI Computer Consulting, Inc. -- http://omniti.com/

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tatsuo Ishii 2009-12-10 00:20:18 Re: [PATCH] Windows x64 [repost]
Previous Message Andrew Dunstan 2009-12-09 23:41:55 Re: explain output infelicity in psql