Re: Nested Wait Events?

On 12 December 2016 at 18:05, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> On Mon, Dec 12, 2016 at 12:16 PM, Simon Riggs <simon(at)2ndquadrant(dot)com> wrote:
>> 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.
>
> Granted.
>
>> 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.
>
> So, I think that this may be a case where I built an apple and you are
> complaining that it's not an orange. I had very clearly in mind from
> the beginning of the wait event work that we were trying to expose
> low-level information about what the system was doing, and I advocated
> for this design as a way of doing that, I think, reasonably well. The
> statement that you want information about what is going on at a higher
> level is fair, but IMHO it's NOT fair to present that as a defect in
> what's been committed. It was never intended to do that, at least not
> by me, and I committed all of the relevant patches and had a fair
> amount of involvement with the design. You may think I should have
> been trying to solve a different problem and you may even be right,
> but that is a separate issue from how well I did at solving the
> problem I was attempting to solve.

There's too many "I"s in that para. I've not presented this as a
defect, nor is there any reason to believe this post is aimed at you
personally.

I'm letting Hackers know that I've come across two problems and I see
more. I'm good with accepting reduced scope in return for performance,
but we should be allowed to discuss what limitations that imposes
without rancour.

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