Received: from localhost (maia-3.hub.org [200.46.204.184]) by postgresql.org (Postfix) with ESMTP id D11A59FB231 for ; Wed, 29 Nov 2006 14:47:04 -0400 (AST) Received: from postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.204.184]) (amavisd-new, port 10024) with ESMTP id 57508-07 for ; Wed, 29 Nov 2006 14:46:45 -0400 (AST) X-Greylist: from auto-whitelisted by SQLgrey-1.7.4 Received: from floppy.pyrenet.fr (floppy.pyrenet.fr [194.116.145.2]) by postgresql.org (Postfix) with ESMTP id 9BA9A9FB21D for ; Wed, 29 Nov 2006 14:46:51 -0400 (AST) Received: by floppy.pyrenet.fr (Postfix, from userid 106) id 249D430AF7; Wed, 29 Nov 2006 19:46:50 +0100 (MET) From: Ron Mayer X-Newsgroups: pgsql.performance Subject: Re: RES: Priority to a mission critical transaction Date: Wed, 29 Nov 2006 10:47:00 -0800 Organization: Hub.Org Networking Services Lines: 66 Message-ID: <456DD5A4.7030309@cheapcomplexdevices.com> References: <4939.1164740825@sss.pgh.pa.us> <200611282344.kASNijt09203@momjian.us> <456CE066.50803@cheapcomplexdevices.com> <456D8A65.3080400@janestcapital.com> <1164812624.9690.500.camel@archimedes> <456DA476.4000606@janestcapital.com> <456DB8C9.7020206@cheapcomplexdevices.com> <456DC19B.4020607@janestcapital.com> Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@news.hub.org To: Brian Hurt User-Agent: Icedove 1.5.0.7 (X11/20061013) In-Reply-To: <456DC19B.4020607@janestcapital.com> To: pgsql-performance@postgresql.org X-Virus-Scanned: Maia Mailguard 1.0.1 X-Archive-Number: 200611/270 X-Sequence-Number: 22040 Brian Hurt wrote: > Ron Mayer wrote: >> Brian Hurt wrote: >>> Mark Lewis wrote: >>>> On Wed, 2006-11-29 at 08:25 -0500, Brian Hurt wrote: >>>>> But, especially given priority inheritance, is there any > > That second paper is interesting in that it says that STM solves the > priority inversion problem. Basically the higher priority process > forces the lower priority process to abort it's transaction and retry it. > > Is it possible to recast Postgres' use of locks to use STM instead? If I read the CMU paper right (http://www.cs.cmu.edu/~bianca/icde04.pdf), that's equivalent to what they call "preemptive abort scheduling" and tested as well as priority inversion. They did test this and compared it to priority inversion with postgresql and found them about equivalent. "Preemptive scheduling (P-LQ and P-CPU) attempts to eliminate the wait excess for high-priority transactions by preempting low-priority lock holders in the way of high-priority transactions. We find that preemptive policies provide little benefit ... TPC-C running on PostgreSQL ... Preemption (P-CPU) provides no appreciable benefit over CPU-Prio-Inherit." > Setting priorities would be a solution to a problem I haven't hit yet, > but can see myself needing to deal with. Which is why I'm interested in > this issue. If it's a case of "setting priorities can make things > better, and doesn't make things worse" is great. If it's a case of > "setting priorities can make things better, but occassionally makes > things much worse" is a problem.