Re: INSERT ... ON CONFLICT {UPDATE | IGNORE}
От | Peter Geoghegan |
---|---|
Тема | Re: INSERT ... ON CONFLICT {UPDATE | IGNORE} |
Дата | |
Msg-id | CAM3SWZTeHWzgAPgiBOfw-6v_Shr7CbjAouOoE-Y2Vt_vBB6nuA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: INSERT ... ON CONFLICT {UPDATE | IGNORE} (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: INSERT ... ON CONFLICT {UPDATE | IGNORE}
|
Список | pgsql-hackers |
On Wed, Sep 3, 2014 at 9:51 AM, Robert Haas <robertmhaas@gmail.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
В списке pgsql-hackers по дате отправления: