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

Поиск
Список
Период
Сортировка
От Peter Geoghegan
Тема Re: INSERT ... ON CONFLICT {UPDATE | IGNORE}
Дата
Msg-id CAM3SWZSd0Jw2fweX4wxU6Z9TtU-X-YFJ+k8LSpgkSyxFdYEEHA@mail.gmail.com
обсуждение исходный текст
Ответ на Re: INSERT ... ON CONFLICT {UPDATE | IGNORE}  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: INSERT ... ON CONFLICT {UPDATE | IGNORE}  (Peter Geoghegan <pg@heroku.com>)
Список pgsql-hackers
On Thu, Sep 4, 2014 at 8:03 AM, Robert Haas <robertmhaas@gmail.com> wrote:
> I think there shouldn't be any plan nodes in the system that don't get
> displayed by explain.  If you're using a plan node for something, and
> think it shouldn't be displayed by explain, then either (1) you are
> wrong or (2) you are abusing the plan node.

Maybe. I admit that I'm not entirely confident that the representation
of the auxiliary state during planning and execution is ideal.
However, it sure is convenient to be able to separately plan the
auxiliary query as a subquery, and not have to specially fish it out
of the subplan list later. Maybe we should add a mechanism that
essentially generates an equivalent, single ModifyTable plan. Or maybe
that would be adding a lot of code for no tangible benefit. I don't
see much point in making one ModifyTable node pull up from the other
for the benefit of this feature (which is another thing entirely to
having there be a single ModifyTable plan). For now, I'm glad to have
something that will allow us to drive discussion of the feature to the
next level. I don't have a good enough understanding of the optimizer
to be able to say with confidence what we should do, or to be able to
see the big picture of making any particular trade-off. It's not an
immediate concern, though.

-- 
Peter Geoghegan



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Pavel Stehule
Дата:
Сообщение: Re: PL/pgSQL 2
Следующее
От: David G Johnston
Дата:
Сообщение: Re: Pg_upgrade and toast tables bug discovered