On 12 December 2016 at 16:52, Robert Haas <robertmh...@gmail.com> wrote: > On Mon, Dec 12, 2016 at 11:33 AM, Simon Riggs <si...@2ndquadrant.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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
