Re: INSERT ... ON CONFLICT UPDATE/IGNORE 4.0

From: Peter Geoghegan <pg(at)heroku(dot)com>
To: Andres Freund <andres(at)anarazel(dot)de>
Cc: hlinnaka <hlinnaka(at)iki(dot)fi>, Jeff Janes <jeff(dot)janes(at)gmail(dot)com>, Stephen Frost <sfrost(at)snowman(dot)net>, Dean Rasheed <dean(dot)a(dot)rasheed(at)gmail(dot)com>, Bruce Momjian <bruce(at)momjian(dot)us>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: INSERT ... ON CONFLICT UPDATE/IGNORE 4.0
Date: 2015-05-06 19:47:43
Message-ID: CAM3SWZS2aWL56NnMcgcGJcUETMBavL9w_-miyAV1q2PLG6OBNA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-admin pgsql-hackers

On Wed, May 6, 2015 at 8:20 AM, Andres Freund <andres(at)anarazel(dot)de> wrote:
> On 2015-05-05 15:00:56 -0700, Peter Geoghegan wrote:
>> Locking the row is not "nothing", though. If you want to lock the row,
>> use an UPSERT with a tautologically false WHERE clause (like "WHERE
>> false").
>
> That's not the same. For one it "breaks" RETURNING which is a death
> knell, for another it's not exactly obvious.

DO NOTHING already doesn't project non-inserted tuples, in a way that
fits with the way we won't do that when a before trigger returns NULL.
So I don't know what you mean about RETURNING behavior.

It may not be all that obvious, but then the requirement that you
mention isn't either. I really strongly feel that DO NOTHING should do
nothing. For the pgloader use-case, which is what I have in mind with
that variant, that could literally make the difference between
dirtying an enormous number of buffers and dirtying only a few. This
will *frequently* be the case. And it's not as if the idea of an
INSERT IGNORE is new or in any way novel. As I mentioned, many systems
have a comparable command.

So, yes, DO NOTHING does very little - and that is its appeal.
Supporting this behavior does not short change those who actually care
about the existing tuple sticking around for the duration of their
transaction - they have a way of doing that. If you want to document
INSERT IGNORE as being primarily an ETL-orientated thing, that would
make sense, but let's not hobble that use case.

--
Peter Geoghegan

In response to

Responses

Browse pgsql-admin by date

  From Date Subject
Next Message Heikki Linnakangas 2015-05-06 19:51:43 Re: INSERT ... ON CONFLICT UPDATE/IGNORE 4.0
Previous Message Peter Geoghegan 2015-05-06 18:27:49 Re: INSERT ... ON CONFLICT UPDATE/IGNORE 4.0

Browse pgsql-hackers by date

  From Date Subject
Next Message Heikki Linnakangas 2015-05-06 19:51:43 Re: INSERT ... ON CONFLICT UPDATE/IGNORE 4.0
Previous Message Peter Geoghegan 2015-05-06 18:43:19 Re: INSERT ... ON CONFLICT syntax issues