From: | Geoff Winkless <pgsqladmin(at)geoff(dot)dj> |
---|---|
To: | Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: INSERT ... ON CONFLICT {UPDATE | IGNORE} 2.0 |
Date: | 2015-02-02 14:32:07 |
Message-ID: | CAEzk6fdaHzGoGDbQe4cHfhu7MnKynaLd6e5C-_=drAcYYGkSdQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 30 January 2015 at 21:58, Peter Geoghegan <pg(at)heroku(dot)com> wrote:
> On Fri, Jan 30, 2015 at 6:59 AM, Geoff Winkless <pgsqladmin(at)geoff(dot)dj> wrote:
>> I suppose there's no reason why we couldn't use a no-op ON CONFLICT
>> UPDATE anyway
>
> Right. IGNORE isn't really all that compelling for that reason. Note
> that this will still lock the unmodified row, though.
Mmmf. So I would have to make sure that my source tuples were unique
before doing the INSERT (otherwise the first ON CONFLICT UPDATE for a
tuple would block any other)? That's potentially very slow :(
When you say that you can't add exclusion constraints later, do you
mean from a coding point of view or just because people would get
confused whether exclusion constraints could be IGNOREd or not?
Geoff
From | Date | Subject | |
---|---|---|---|
Next Message | Magnus Hagander | 2015-02-02 14:38:35 | Re: Small doc patch about pg_service.conf |
Previous Message | Andres Freund | 2015-02-02 14:21:06 | Re: Redesigning checkpoint_segments |