From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Jeff Janes <jeff(dot)janes(at)gmail(dot)com> |
Cc: | Heikki Linnakangas <hlinnakangas(at)vmware(dot)com>, 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-27 14:30:27 |
Message-ID: | CA+TgmoYF90arXen7zSqoJFzjRffVjpQEsBXwhvTmm4oGW5z_gg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, Jun 26, 2013 at 5:49 PM, Jeff Janes <jeff(dot)janes(at)gmail(dot)com> wrote:
> 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.
I think it has little risk. If it turns out to be worse for
performance, we can always revert it, but I expect it'll be better or
a wash, and the results so far seem to bear that out. Another
interesting question is whether we should fool with the actual values
for minimum and maximum delays, but that's a separate and much harder
question, so I think we should just do this for now and call it good.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2013-06-27 14:33:44 | Re: [PATCH] add long options to pgbench (submission 1) |
Previous Message | Kevin Grittner | 2013-06-27 14:25:12 | Re: refresh materialized view concurrently |