Re: [HACKERS] Nested Wait Events?

Поиск
Список
Период
Сортировка
От Simon Riggs
Тема Re: [HACKERS] Nested Wait Events?
Дата
Msg-id CANP8+jJJNNeR640U4cs_Tdc7SjUJdCqKVq-6=FT46aUjsmc=Mg@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [HACKERS] Nested Wait Events?  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: [HACKERS] Nested Wait Events?  (Robert Haas <robertmhaas@gmail.com>)
Список pgsql-hackers
On 12 December 2016 at 18:05, Robert Haas <robertmhaas@gmail.com> wrote:
> On Mon, Dec 12, 2016 at 12:16 PM, Simon Riggs <simon@2ndquadrant.com> wrote:
>> On 12 December 2016 at 16:52, Robert Haas <robertmhaas@gmail.com> wrote:
>>> On Mon, Dec 12, 2016 at 11:33 AM, Simon Riggs <simon@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.
>
> 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



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Peter Geoghegan
Дата:
Сообщение: Re: [HACKERS] tuplesort_gettuple_common() and *should_free argument
Следующее
От: Tom Lane
Дата:
Сообщение: Re: [HACKERS] [COMMITTERS] pgsql: Add support for temporary replication slots