On Wed, Jun 26, 2013 at 5:49 PM, Jeff Janes <jeff.ja...@gmail.com> wrote: > On Tue, Jun 18, 2013 at 12:09 AM, Heikki Linnakangas > <hlinnakan...@vmware.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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers