From: | Peter Geoghegan <pg(at)heroku(dot)com> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | Heikki Linnakangas <hlinnakangas(at)vmware(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>, Andres Freund <andres(at)2ndquadrant(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Subject: | Re: INSERT...ON DUPLICATE KEY LOCK FOR UPDATE |
Date: | 2014-01-13 20:53:29 |
Message-ID: | CAM3SWZS+o6=i=EeAVLgrXdQRwcC8h2E9rfoBsfV2qOfgutRLDA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, Jan 13, 2014 at 12:17 PM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> For what it's worth, I agree with Heikki. There's probably nothing
> sensible an upsert can do if it conflicts with more than one tuple,
> but if it conflicts with just exactly one, it oughta be OK.
If there is exactly one, *and* the existing value is exactly the same
as the value proposed for insertion (or, I suppose, a subset of the
existing value, but that's so narrow that it might as well not apply).
In short, when you're using an exclusion constraint as a unique
constraint. Which is very narrow indeed. Weighing the costs and the
benefits, that seems like far more cost than benefit, before we even
consider anything beyond simply explaining the applicability and
limitations of upserting with exclusion constraints. It's generally
far cleaner to define speculative insertion as something that happens
with unique indexes only.
--
Peter Geoghegan
From | Date | Subject | |
---|---|---|---|
Next Message | Trond Myklebust | 2014-01-13 20:53:36 | Re: [Lsf-pc] Linux kernel impact on PostgreSQL performance |
Previous Message | Robert Haas | 2014-01-13 20:48:56 | Re: Planning time in explain/explain analyze |