Comment 6 for bug 618019

As explained in the summary, we are regularly encountering situations
for which a very plausible scenario is 'reading from the raw cursor is
blocking', and requests are spending 10 or more seconds in storm code
paths.

Either its storm, or its the DB itself.

We want to know systematically, not case by case, so that when this
happens developers can immediately address the issue rather than
roundtripping via sysadmins.

There are all sorts of things potentially using time up in reading from cursors:
 - networking
 - work in other threads in python
 - db side buffering

So we won't know which of these is the case - but we don't for our
existing traces either, because we're a threaded app in python, so its
no *less* accurate, and we find the existing timing data extremely
useful.

I don't understand why you would want to avoid being able to gather
evidence about where the time is going in an systematic way cleanly
integrated into the codebase.