Re: Spin Lock sleep resolution

From: Jeff Janes <jeff(dot)janes(at)gmail(dot)com>
To: Heikki Linnakangas <hlinnakangas(at)vmware(dot)com>
Cc: David Gould <daveg(at)sonic(dot)net>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Spin Lock sleep resolution
Date: 2013-06-26 21:49:46
Message-ID: CAMkU=1yASyHbH44jMkwtyj=SPjQ3x1GOhTdazrXuFEs1yUhYiA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Jun 18, 2013 at 12:09 AM, Heikki Linnakangas <
hlinnakangas(at)vmware(dot)com> wrote:

>
> Jeff's patch seems to somewhat alleviate the huge fall in performance I'm
> otherwise seeing without the nonlocked-test patch. With the nonlocked-test
> patch, if you squint you can see a miniscule benefit.
>
> I wasn't expecting much of a gain from this, just wanted to verify that
> it's not making things worse. So looks good to me.

Hi Heikki,

Thanks for trying out the patch.

I see in the commitfest app it is set to "Waiting on Author" (but I don't
know who "maiku41" is).

Based on the comments so far, I don't know what I should be doing on it at
the moment, and I thought perhaps your comment above meant it should be
"ready for committer".

If we think the patch has a risk of introducing subtle errors, then it
probably can't be justified based on the small performance gains you saw.

But if we think it has little risk, then I think it is justified simply
based on cleaner code, and less confusion for people who are tracing a
problematic process. If we want it to do a random escalation, it should
probably look like a random escalation to the interested observer.

Thanks,

Jeff

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Alvaro Herrera 2013-06-26 22:05:00 Re: Spin Lock sleep resolution
Previous Message Noah Misch 2013-06-26 21:48:14 Re: MD5 aggregate