Re: WIP patch for multiple column assignment in UPDATE
От | Robert Haas |
---|---|
Тема | Re: WIP patch for multiple column assignment in UPDATE |
Дата | |
Msg-id | CA+TgmoYNwPsVwMn4oxcbhGNJ9=S-K+VjH8rkwyEaMkH60au09A@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: WIP patch for multiple column assignment in UPDATE (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
On Thu, Jun 19, 2014 at 9:37 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Pavel Stehule <pavel.stehule@gmail.com> writes: >> I did some tests and It looks so it allows only some form of nested loop. > > [ shrug... ] It's a subplan. One evaluation per outer row is what > people are expecting. Is it theoretically possible to convert a construct like this to a semi-join? I notice we don't, even when this new syntax isn't used: rhaas=# explain select a, (select b from bar where foo.a = bar.a) from foo; QUERY PLAN ------------------------------------------------------------Seq Scan on foo (cost=0.00..855145.00 rows=10000 width=4) SubPlan1 -> Seq Scan on bar (cost=0.00..85.50 rows=1 width=4) Filter: (foo.a = a)Planning time: 0.078 ms ...but I'm wondering if that's an unimplemented feature or if there's some reason why it's a bad idea. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления: