Received: from localhost (unknown [200.46.208.211]) by mail.postgresql.org (Postfix) with ESMTP id 8DA206342DA for ; Fri, 20 Mar 2009 21:45:32 -0300 (ADT) Received: from mail.postgresql.org ([200.46.204.86]) by localhost (mx1.hub.org [200.46.208.211]) (amavisd-maia, port 10024) with ESMTP id 31739-02 for ; Fri, 20 Mar 2009 21:45:22 -0300 (ADT) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from yx-out-2324.google.com (yx-out-2324.google.com [74.125.44.29]) by mail.postgresql.org (Postfix) with ESMTP id D9FA7634287 for ; Fri, 20 Mar 2009 21:45:29 -0300 (ADT) Received: by yx-out-2324.google.com with SMTP id 8so835583yxm.73 for ; Fri, 20 Mar 2009 17:45:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=+dKTsXMiJq+9SHKIR2UYq3d3C1ZQpDOyKgBtlBibEvU=; b=QXWdzwqdNs7apphhLmN+FNkpL9w/5+nVHAz6kEmsCxfNJCg4uBCoqFbIhaJhfZZhKM dEXvNY9nRtfWVkFnrgNm3m5beNz2isgKYAAd28oyMJXxARn5HLCW7sGXLRkqbwvUwXfd XYDKhrBZ0EDryXzbwWuI93LcGdyO+JrmfUQug= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=v9VbB6J3ke/DCrhdQiljvPPbbGZl68uXHzVvisRnOFdLjHRKfI14b7r0IfhAdDgiTq 6llRwf6dJ8m52ddMQiJYieyJR4Pf8F1+MHfZ2SiHcuY0s6EQ5dxu1DptCMhXtKdBtqup lDMeeGalAnyG/DrAQ1FUldBmC8xWMVRTiqNLY= MIME-Version: 1.0 Received: by 10.100.126.19 with SMTP id y19mr2240148anc.130.1237596328130; Fri, 20 Mar 2009 17:45:28 -0700 (PDT) In-Reply-To: <49C42921.8050508@sun.com> References: <603c8f070903191349p5e8fb00as2816581d584fcefd@mail.gmail.com> <20090320154601.GC8313@alvh.no-ip.org> <20090320215813.GR8313@alvh.no-ip.org> <20090320220513.GS8313@alvh.no-ip.org> <49C42921.8050508@sun.com> Date: Fri, 20 Mar 2009 20:45:28 -0400 Message-ID: <603c8f070903201745m575642f5s539e1a374ce4ce9f@mail.gmail.com> Subject: Re: Proposal of tunable fix for scalability of 8.4 From: Robert Haas To: "Jignesh K. Shah" Cc: Alvaro Herrera , Scott Carey , Greg Smith , Kevin Grittner , "pgsql-performance@postgresql.org" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=0 tagged_above=0 required=5 tests=none X-Spam-Level: X-Archive-Number: 200903/313 X-Sequence-Number: 33235 On Fri, Mar 20, 2009 at 7:39 PM, Jignesh K. Shah wrote: > Alvaro Herrera wrote: >>> So Simon's correct. >> And perhaps this explains why Jignesh is measuring an improvement on his >> benchmark. =A0Perhaps an useful experiment would be to turn this behavio= r >> off and compare performance. =A0This lack of measurement is probably the >> cause that the suggested patch to fix it was never applied. >> >> The patch is here >> http://archives.postgresql.org//pgsql-hackers/2004-11/msg00935.php > > One of the reasons why my patch helps is it keeps this check intact but > allows other exclusive Wake up.. Now what PostgreSQL calls "Wakes" is =A0= in > reality just makes a variable indicating wake up and not really signallin= g a > process to wake up. This is a key point to note. So when the process want= ing > the exclusive fights the OS Scheduling policy to finally get time on the = CPU > then it =A0 check the value to see if it is allowed to wake up and potent= ially I'm confused. Is a process waiting for an LWLock is in a runnable state? I thought we went to sleep on a semaphore. ...Robert