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
---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
