| From: | Peter Geoghegan <pg(at)heroku(dot)com> |
|---|---|
| To: | Greg Stark <stark(at)mit(dot)edu> |
| Cc: | Jim Nasby <jim(at)nasby(dot)net>, Heikki Linnakangas <hlinnakangas(at)vmware(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>, Robert Haas <robertmhaas(at)gmail(dot)com>, 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-11 06:48:35 |
| Message-ID: | CAM3SWZSPb5Mf6Wqn9YWm6k8QYGKN7H9HKzcph9mw5nJ3-Zb2Ww@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Fri, Jan 10, 2014 at 10:01 PM, Greg Stark <stark(at)mit(dot)edu> wrote:
>> So you schedule a class that clashes with 3 other classes, and you
>> want to update all 3 rows/classes with details from your one row
>> proposed for insertion?
>
>
> Well, perhaps you want to mark the events as conflicting with your new event?
But short of a sophisticated persistent value locking implementation
(which I'm pretty skeptical of the feasibility of), more conflicting
events could be added at any moment. I doubt that you're appreciably
any better off than if you were to simply check with a select query,
even though that approach is obviously broken. In general, making row
locking work for exclusion constraints, so you can treat them in a way
that allows you to merge on arbitrary operators seems to me like a tar
pit.
--
Peter Geoghegan
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Craig Ringer | 2014-01-11 07:57:07 | [PATCH] Fix double-inclusion of pg_config_os.h when building extensions with Visual Studio |
| Previous Message | Amit Kapila | 2014-01-11 06:08:38 | Re: Performance Improvement by reducing WAL for Update Operation |