| 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 |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| 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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Andrew - Supernews | 2007-03-02 18:41:08 | Re: GIST and TOAST |
| Previous Message | Tom Lane | 2007-03-02 18:39:21 | Re: UPSERT |