Received: from localhost (unknown [200.46.204.183])
	by developer.postgresql.org (Postfix) with ESMTP id 64EB42E002D
	for <pgsql-performance-postgresql.org@developer.postgresql.org>;
	Wed,  2 Apr 2008 16:16:11 -0300 (ADT)
Received: from developer.postgresql.org ([200.46.204.71])
	by localhost (mx1.hub.org [200.46.204.183]) (amavisd-maia, port 10024)
	with ESMTP id 51380-02
	for <pgsql-performance-postgresql.org@developer.postgresql.org>;
	Wed,  2 Apr 2008 16:15:56 -0300 (ADT)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.5
Received: from pih-relay06.plus.net (pih-relay06.plus.net [212.159.14.133])
	by developer.postgresql.org (Postfix) with ESMTP id 36E642E0050
	for <pgsql-performance@postgresql.org>;
	Wed,  2 Apr 2008 16:15:55 -0300 (ADT)
Received: from [80.229.150.39] (helo=mansionfamily.plus.com)
	by pih-relay06.plus.net with esmtp (Exim) id 1Jh8R7-0000iZ-K8
	for pgsql-performance@postgresql.org; Wed, 02 Apr 2008 20:15:53 +0100
Received: from [192.168.0.89] ([192.168.0.89]:1688)
	by mansionfamily.plus.com with [XMail 1.22 ESMTP Server]
	id <S15437> for <pgsql-performance@postgresql.org> from
	<james@mansionfamily.plus.com>; Wed, 2 Apr 2008 20:20:53 +0100
Message-ID: <47F3DC5A.30705@mansionfamily.plus.com>
Date: Wed, 02 Apr 2008 20:19:54 +0100
From: James Mansion <james@mansionfamily.plus.com>
Organization: MsgWare
User-Agent: Thunderbird 2.0.0.0 (Windows/20070326)
MIME-Version: 1.0
To: Stephen Denne <Stephen.Denne@datamail.co.nz>
CC: Ravi Chemudugunta <chemuduguntar@gmail.com>,
	pgsql-performance@postgresql.org
Subject: Re: Performance Implications of Using Exceptions
References: <7a4208ef0803311720s1dac8362gff2477d3dc534968@mail.gmail.com>
	<20080401005235.GM4999@tamriel.snowman.net>
	<F0238EBA67824444BC1CB4700960CB4804F8B1BA@dmpeints002.isotach.com>
In-Reply-To: 
 <F0238EBA67824444BC1CB4700960CB4804F8B1BA@dmpeints002.isotach.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Plusnet-Relay: 3bd69ac5fc27340835bc38263af4ebbb
X-Virus-Scanned: Maia Mailguard 1.0.1
X-Archive-Number: 200804/21
X-Sequence-Number: 29514

Stephen Denne wrote:
> A third option is to update, if not found, insert.
>
>   
I find myself having to do this in Sybase, but it sucks because there's
a race - if there's no row updated then there's no lock and you race
another thread doing the same thing. So you grab a row lock on a
sacrificial row used as a mutex, or just a table lock. Or you just
accept that sometimes you have to detect the insert fail and retry the
whole transaction. Which is sucky however you look at it.

I think the 'update or insert' or 'merge' extensions make a degree
of sense. At least in psql one can use the lightweight lock manager.