Re: ask for review of MERGE

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Greg Smith <greg(at)2ndquadrant(dot)com>
Cc: Marko Tiikkaja <marko(dot)tiikkaja(at)cs(dot)helsinki(dot)fi>, Boxuan Zhai <bxzhai2010(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: ask for review of MERGE
Date: 2010-10-23 16:12:44
Message-ID: 13452.1287850364@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Greg Smith <greg(at)2ndquadrant(dot)com> writes:
> Marko Tiikkaja wrote:
>> What's been bothering me is that so far there has not been an
>> agreement on whether we need to protect against concurrency issues or
>> not. In fact, there has been almost no discussion about the
>> concurrency issues which AIUI have been the biggest single reason we
>> don't have MERGE already.

> Sure there were, they just happened a long time ago. I tried to
> summarize the previous discussion at
> http://wiki.postgresql.org/wiki/SQL_MERGE with the following:

> "PostgreSQL doesn't have a good way to lock access to a key value that
> doesn't exist yet--what other databases call key range
> locking...Improvements to the index implementation are needed to allow
> this feature."

This seems to be presuming there's a consensus that that's the way to
implement it, which is news to me. Why wouldn't we try the INSERT
first, and if we get a unique-key failure, do UPDATE instead? I am not
at all in agreement that we ought to build key range locking, nor that
it'd be particularly helpful for this problem even if we had it.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Jesper Krogh 2010-10-23 16:25:33 window function count(*) and limit
Previous Message Greg Smith 2010-10-23 14:31:05 Re: ask for review of MERGE