Re: INSERT ... ON CONFLICT {UPDATE | IGNORE}
От | Robert Haas |
---|---|
Тема | Re: INSERT ... ON CONFLICT {UPDATE | IGNORE} |
Дата | |
Msg-id | CA+TgmoZ4jt+n+FHVYY2OJm5WO_UGD9=JDq7tdrQGiB_cKKjQmA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: INSERT ... ON CONFLICT {UPDATE | IGNORE} (Peter Geoghegan <pg@heroku.com>) |
Ответы |
Re: INSERT ... ON CONFLICT {UPDATE | IGNORE}
|
Список | pgsql-hackers |
On Wed, Sep 3, 2014 at 2:13 PM, Peter Geoghegan <pg@heroku.com> wrote: > 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. 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. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления: