| 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: | Whole Thread | Raw Message | 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 |