Re: INSERT ... ON CONFLICT {UPDATE | IGNORE}

From: Peter Geoghegan <pg(at)heroku(dot)com>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Pg Hackers <pgsql-hackers(at)postgresql(dot)org>, Craig Ringer <craig(at)2ndquadrant(dot)com>
Subject: Re: INSERT ... ON CONFLICT {UPDATE | IGNORE}
Date: 2014-09-03 18:13:27
Message-ID: CAM3SWZTeHWzgAPgiBOfw-6v_Shr7CbjAouOoE-Y2Vt_vBB6nuA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Sep 3, 2014 at 9:51 AM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>> Essentially, the implementation has all stages of query processing
>> During the execution of the parent ModifyTable, a special auxiliary
>> subquery (the UPDATE ModifyTable) is considered as a special case.
>> This is not a subplan of the ModifyTable node in the conventional
>> sense, and so does not appear within EXPLAIN output.
>
> ...that sounds wonky.

Which part? It certainly wouldn't be helpful if the (say) auxiliary
plan's "sequential scan" appeared within EXPLAIN output. That's just
an implementation detail. Note that the structure of the plan is
highly restricted, since it needs to be "driven by the insert" (or,
rather, the insert's conflicts, including conflicts not visible to the
command's MVCC snapshot). There won't be any interesting variation in
the plan. Although, that said, the implementation should probably
display any "Filter: ..." conditions implied by the special UPDATE
qual.

> If you've noted my comments on the UPDATE/DELETE .. ORDER BY .. LIMIT
> thread, you won't be surprised to hear that I think those restrictions
> will need to be lifted - especially for inheritance, but probably the
> others as well.

Sure.

--
Peter Geoghegan

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2014-09-03 18:48:45 Re: PL/pgSQL 2
Previous Message Álvaro Hernández Tortosa 2014-09-03 17:45:35 Re: PL/pgSQL 2