Re: Nested Wait Events?

On 12 December 2016 at 16:52, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> On Mon, Dec 12, 2016 at 11:33 AM, Simon Riggs <simon(at)2ndquadrant(dot)com> wrote:
>> Last week I noticed that the Wait Event/Locks system doesn't correctly
>> describe waits for tuple locks because in some cases that happens in
>> two stages.
>
> Well, I replied to that email to say that I didn't agree with your
> analysis. I think if something happens in two stages, those wait
> events should be distinguished. The whole point here is to get
> clarity on what the system is waiting for, and we lose that if we
> start trying to merge together things which are at the code level
> separate.

Clarity is what we are both looking for then.

I know I am waiting for a tuple lock. You want information about all
the lower levels. I'm good with that as long as the lower information
is somehow recorded against the higher level task, which it wouldn't
be in either of the cases I mention, hence why I bring it up again.

Same thing occurs in any case where we wait for multiple lwlocks.

"I had to buy a mop so I could clean the toilets" is potentially
important information, but I would prefer to start at the intention
side. So that "cleaning the toilets" shows up as the intent, which
might consist of multiple sub-tasks. We can then investigate why
sometimes cleaning the toilet takes one flush and other times it
involves a shopping trip to get a mop. If "mop purchase" is not
correctly associated with cleaning then we don't notice what is going
on and cannot do anything useful with the info.

Regrettably, it's an accounting problem not a database problem and we
need a chart of accounts hierarchy to solve it. (e.g. bill of
materials).

--
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services