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
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 |