Received: from localhost (unknown [200.46.208.211]) by mail.postgresql.org (Postfix) with ESMTP id 870F1635253 for ; Thu, 12 Mar 2009 22:30:08 -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 03328-03 for ; Thu, 12 Mar 2009 22:29:47 -0300 (ADT) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.235]) by mail.postgresql.org (Postfix) with ESMTP id E38A8633AE5 for ; Thu, 12 Mar 2009 22:29:54 -0300 (ADT) Received: by rv-out-0506.google.com with SMTP id f6so1421135rvb.43 for ; Thu, 12 Mar 2009 18:29:53 -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=FnO5SVM2na59+unTJz+4PZSk3cyjXz3087i/pNOD/Jg=; b=IFLoyW6c493+hvdHxoQI3/G5ZFu+nl8OMz5NJJmB0ovpeLgXgR7eUG6WZWpV0gv8sQ o1OMJ9yrgbL6Qhrany8EMvEMkFJTn5B85g96PkkdpDsw6qYwQuhQDiZF1dUaCt9WTXkX 7NFK1JpVfqQdx/epv5q07l2RhJCt1xmnwAw2Y= 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=xuIqt0oNWqSbdPOmM9pJ5/Qi4dcTmPTqXFr4sZrwBP+/QAYRoVEmtYJ5jEDCtxm1Z4 3AeTTzc4IO2QsBib6BhsZGl/f2g4+yuhiPjCD5CdgNOhcs8FYd7Am6ZcwrGwwIR0v3Tu K4iEmH9+ET9+v48xYv3H8ThHv6sQ4G1kT55LA= MIME-Version: 1.0 Received: by 10.114.157.1 with SMTP id f1mr397301wae.43.1236907793018; Thu, 12 Mar 2009 18:29:53 -0700 (PDT) In-Reply-To: References: Date: Thu, 12 Mar 2009 21:29:52 -0400 Message-ID: <603c8f070903121829r31cf1472ha9876e5c480a542e@mail.gmail.com> Subject: Re: Proposal of tunable fix for scalability of 8.4 From: Robert Haas To: Scott Carey Cc: Greg Smith , "Jignesh K. Shah" , Kevin Grittner , "pgsql-performance@postgresql.org" Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=0.258 tagged_above=0 required=5 tests=AWL=0.258 X-Spam-Level: X-Archive-Number: 200903/146 X-Sequence-Number: 33068 > Its worth ruling out given that even if the likelihood is small, the fix = is > easy. =A0However, I don=92t see the throughput drop from peak as more > concurrency is added that is the hallmark of this problem =97 usually wit= h a > lot of context switching and a sudden increase in CPU use per transaction= . The problem is that the proposed "fix" bears a strong resemblence to attempting to improve your gas mileage by removing a few non-critical parts from your card, like, say, the bumpers, muffler, turn signals, windshield wipers, and emergency brake. While it's true that the car might be drivable in that condition (as long as nothing unexpected happens), you're going to have a hard time convincing the manufacturer to offer that as an options package. I think that changing the locking behavior is attacking the problem at the wrong level anyway. If someone want to look at optimizing PostgreSQL for very large numbers of concurrent connections without a connection pooler... at least IMO, it would be more worthwhile to study WHY there's so much locking contention, and, on a lock by lock basis, what can be done about it without harming performance under more normal loads? The fact that there IS locking contention is sorta interesting, but it would be a lot more interesting to know why. ...Robert