Greg Stark wrote:
>It seems pointless to me to expose things like lwlock_acuire that map 1-1 to C
>function calls like LWLockAcquire. They're useless except to people who
>understand what's going on and if people know the low level implementation
>details of Postgres they can already trace those calls with dtrace without any
>help.
>
>
>
lwlock_acquire is just an example. I think once we decided to down this
path, we can solicit ideas for interesting probes and put them up for
discussion on this alias whether or not they are needed. I think we need
to have two categories of probes for admins and developers. Perhaps the
probes for admins are more important since, as you said, the developers
already know which function does what, but I think the low-level probes
are still useful for new developers as there behavior will be documented.
>What would be useful is instrumenting high level calls that can't be traced
>without application guidance. For example, inserting a dtrace probe for each
>SQL and each plan node. That way someone could get the same info as EXPLAIN
>ANALYZE from a production server without having to make application
>modifications (or suffer the gettimeofday overhead).
>
>
>It's one thing to know "I seem to be acquiring a lot of locks" or "i'm
>spending all my time in sorting". It's another to be able to ask dtrace "what
>query am I running when doing all this sorting?" or "what kind of plan node am
>I running when I'm acquiring all these locks?"
>
>
>
Completely agree.
Regards,
Robert
