Received: from localhost (unknown [200.46.208.211]) by mail.postgresql.org (Postfix) with ESMTP id 0A2D9634AA4 for ; Wed, 18 Mar 2009 20:07:41 -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 21608-01 for ; Wed, 18 Mar 2009 20:07:27 -0300 (ADT) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from outmail129154.authsmtp.co.uk (outmail129154.authsmtp.co.uk [62.13.129.154]) by mail.postgresql.org (Postfix) with ESMTP id D35D0633BC4 for ; Wed, 18 Mar 2009 20:07:33 -0300 (ADT) Received: from mail-c189.authsmtp.com (mail-c189.authsmtp.com [62.13.128.71]) by punt7.authsmtp.com (8.14.2/8.14.2/Kp) with ESMTP id n2IN7Tqd068670; Wed, 18 Mar 2009 23:07:29 GMT Received: from [192.168.0.2] (85-211-223-92.dyn.gotadsl.co.uk [85.211.223.92]) (authenticated bits=0) by mail.authsmtp.com (8.14.2/8.14.2/Kp) with ESMTP id n2IN7Spg074429; Wed, 18 Mar 2009 23:07:28 GMT Subject: Re: Proposal of tunable fix for scalability of 8.4 From: Simon Riggs To: Matthew Wakeling Cc: "Jignesh K. Shah" , "pgsql-performance@postgresql.org" In-Reply-To: References: <603c8f070903121829r31cf1472ha9876e5c480a542e@mail.gmail.com> <12292.1236964604@sss.pgh.pa.us> <49BB699D.1070809@enterprisedb.com> <1237362833.3953.186.camel@ebony.2ndQuadrant> <1237378009.3953.303.camel@ebony.2ndQuadrant> <49C0F946.8080008@sun.com> Content-Type: text/plain Date: Wed, 18 Mar 2009 23:07:34 +0000 Message-Id: <1237417654.3953.320.camel@ebony.2ndQuadrant> Mime-Version: 1.0 X-Mailer: Evolution 2.12.0 Content-Transfer-Encoding: 7bit X-Server-Quench: 8da2bc7f-1411-11de-bc7b-001f29070be2 X-AuthRoute: OCdxZQATClZOTQEd DAteCiNZVAwpPBRK HVkIKg5MJUcNSQVJ NksadRtFaQ1bYFhD HGQLW11EUl57WWR/ aQMfZQBDYEtPQQdo U1ZAQE1QEQdtHhxP WBxnLB4RN1JGf3p0 Z08sXHFbVApyIRd/ EB1TQ3AHYWZhdWEe BBVFJVBTIh5Kfh4T aFl/U3NfNGdJBC9q VzwLEgofGg96HWxt WAYVKkkbRQ4MEHYg WhYLFzEiVUMEV209 KAZuMVUVGE8bM0Ez LUppXlxQY1lOYiwg X-Authentic-SMTP: 61633235383639.kestrel.dmpriest.net.uk:1378/Kp X-Report-SPAM: If SPAM / abuse - report it at: http://www.authsmtp.com/abuse X-Virus-Status: No virus detected - but ensure you scan with your own anti-virus system. X-Virus-Scanned: Maia Mailguard 1.0.1 X-Archive-Number: 200903/262 X-Sequence-Number: 33184 On Wed, 2009-03-18 at 13:49 +0000, Matthew Wakeling wrote: > On Wed, 18 Mar 2009, Jignesh K. Shah wrote: > > I thought about that.. Except without putting a restriction a huge queue will cause lot of time spent in manipulating the lock > > list every time. One more thing will be to maintain two list shared and exclusive and round robin through them for every time you > > access the list so manipulation is low.. But the best thing is to allow flexibility to change the algorithm since some workloads > > may work fine with one and others will NOT. The flexibility then allows to tinker for those already reaching the limits. > > Yeah, having two separate queues is the obvious way of doing this. It > would make most operations really trivial. Just wake everything in the > shared queue at once, and you can throw it away wholesale and allocate a > new queue. It avoids a whole lot of queue manipulation. Yes, that sounds good. -- Simon Riggs www.2ndQuadrant.com PostgreSQL Training, Services and Support