Skip site navigation (1) Skip section navigation (2)

Re: UPSERT

From: "Simon Riggs" <simon(at)2ndquadrant(dot)com>
To: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: "Heikki Linnakangas" <heikki(at)enterprisedb(dot)com>,"Andrew Dunstan" <andrew(at)dunslane(dot)net>,"Jonathan Scher" <js(at)oxado(dot)com>,<pgsql-hackers(at)postgresql(dot)org>
Subject: Re: UPSERT
Date: 2007-03-02 18:39:22
Message-ID: 1172860763.3760.1645.camel@silverbirch.site (view raw or flat)
Thread:
Lists: pgsql-hackers
On Fri, 2007-03-02 at 13:19 -0500, Tom Lane wrote:
> "Simon Riggs" <simon(at)2ndquadrant(dot)com> writes:
> > Seems like we should try to locate a row first, then INSERT if we cannot
> > find one. That's slower on INSERT but more balanced overall
> 
> Except it still has the race condition.

I'm not saying it didn't; but dropping in two dead copies of a tuple
isn't acceptable either.

> > I'm a bit surprised the TODO didn't mention the MERGE statement, which
> > is the SQL:2003 syntax for specifying this as an atomic statement.
> 
> I believe we concluded that MERGE doesn't actually do quite what people
> want/expect.  Please go back and read the archives.

Yes, it was my thread. I recall that there wasn't any acceptable answer
to how it could be done with reasonable efficiency.

-- 
  Simon Riggs             
  EnterpriseDB   http://www.enterprisedb.com



In response to

pgsql-hackers by date

Next:From: Andrew - SupernewsDate: 2007-03-02 18:41:08
Subject: Re: GIST and TOAST
Previous:From: Tom LaneDate: 2007-03-02 18:39:21
Subject: Re: UPSERT

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group