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}  (Robert Haas <robertmhaas@gmail.com>)
Список 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 по дате отправления:

Предыдущее
От: Álvaro Hernández Tortosa
Дата:
Сообщение: Re: PL/pgSQL 2
Следующее
От: Robert Haas
Дата:
Сообщение: Re: PL/pgSQL 2