Re: [HACKERS] Re: [SQL] cursor and update + view
От | Vadim Mikheev |
---|---|
Тема | Re: [HACKERS] Re: [SQL] cursor and update + view |
Дата | |
Msg-id | 365B78F2.F5E791D5@krs.ru обсуждение исходный текст |
Ответ на | Re: [HACKERS] Re: [SQL] cursor and update + view (jwieck@debis.com (Jan Wieck)) |
Ответы |
Re: [HACKERS] Re: [SQL] cursor and update + view
|
Список | pgsql-hackers |
Jan Wieck wrote: > > > rule system will be able to put _any_ VIEW' query into > > FROM clause... > > Possible - but IMHO the wrong thing to do. As it is now for a "Will be able" doesn't mean "will DO" -:)) I just said that subqueries in FROM will resolve all problems with aggregates in VIEWs. > If we put any view into a subquery RTE, we force the planner > to materialize the view and do a nestloop over t3 and ^^^^^^^^^^^ Do you mean creating some tmp table etc? No - it's not required. > materialized v1 where possibly using t1 or t2 as the > outermost scanrelation would be better. SELECT t3.a, v1.b, v1.c FROM t3, (SELECT t1.a, t1.b, t2.c FROM t1, t2 WHERE t1.a = t2.a) v1 WHERE t3.a = v1.a; can be planned as Nestloop SubPlan ...what is costless for subquery... Seq/Index scan on t3 - no materialization... On the other hand, as we talk about query optimization - why rule system should do optimizer' work? Why not just put _any_ VIEW' query into FROM and let optimizer decide could query be rewritten as join or not? Ppl do strange things sometimes -:) Sometimes they use subqueries in WHERE while joins could be used and our optimizer don't try to catch this. I know that Sybase does. And, imho, we should implement this ... sometime -:)) Vadim
В списке pgsql-hackers по дате отправления: