Xref: utzoo comp.object:126 comp.databases:3833 Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!cs.utexas.edu!uunet!mcsun!cernvax!ethz!ethz-inf!scholl From: scholl@inf.ethz.ch (Marc Scholl) Newsgroups: comp.object,comp.databases Subject: Re: Query optimization in OODB Summary: Consider the cost of predicate evaluation, too. Keywords: query optimization, object-oriented DB, extensibility Message-ID: <3656@ethz-inf.UUCP> Date: 10 Oct 89 07:35:20 GMT References: <16958@watdragon.waterloo.edu> Reply-To: scholl@inf.ethz.ch.UUCP (Marc H. Scholl) Followup-To: comp.object Distribution: comp Organization: Departement fuer Informatik, ETH Zuerich Lines: 28 In article <16958@watdragon.waterloo.edu> zmhasan@watdragon.waterloo.edu (Ziaul Masum Hasan) writes: >Could any one out there explain me why the use of a method in a query >predicate (), as an attribute-name or >as an operator, cause difficulties with query compilation and optimization ? > >M Hasan. In addition to Jack Orenstein's response that has been focussing around indexing of "encapsulated attributes" (those that are implemented as methods): A further problem for query optimization stems from the fact that typical (relational) optimizers assume the cost for predicate evaluation to be zero, i.e., once we have loaded the tuple no further costs will be incured by accessing the "" named nor by evaluating the predicate "". However, if either of them is a (user supplied) method, this is no longer true. Hence, a smart OODB query optimizer should estimate the cost of these actions, too. Of course, this means that the implementor of the correspondsing methods has to provide cost estimation functions to assist the optimizer. (This is another example for the need of extensible optimizers.) In the extreme, such situations could make the optimizer postpone a selection past a join (if the join is quite selective and the selection predicate is expensive to evaluate). This is obviously in contrast to the well-known heuristics of pushing selections dwon the expression tree. -Marc