Re: [HACKERS] Re: [SQL] cursor and update + view
От | Vadim Mikheev |
---|---|
Тема | Re: [HACKERS] Re: [SQL] cursor and update + view |
Дата | |
Msg-id | 365CCAB0.CE4B0143@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: > > > 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 -:)) > > Depends on where the optimization is done. If we do it on the > parsetree (Query struct), it's the job of the rule system. > The optimizer does not have to modify the parsetree. If it is > done on the way from the parsetree to the plan, it is the job > of the optimizer. > > If it is possible to do it on the parsetree, I would do it > there. Subquery --> Join transformation/optimization implemented in rule system will be used for Views only. Being implemented in optimizer it will be used in all cases. Vadim
В списке pgsql-hackers по дате отправления: