Native Queries for Persistent Objects A Design White Paper
A final and thorough specification of native queries will only be possible after practical experience. Therefore, this section is speculative. We would like to point out where we see choices and issues with the native query approach and how they might be resolved.
Optimization
Regarding the API alone, native queries are not new. Without optimizations, we have merely provided \the simplest concept possible to run all instances of a class against a method that returns a boolean value”. Such interfaces are well-known: Smalltalk 80 includes methods to select items from a collection based on a predicate [5, 2].
Optimization is the key new component of native queries. Users should be able to write native query expressions and the database should execute them with performance on par with the string-based queries that we described in the introduction to this paper.
Although the core concept of native queries is simple, the work needed to provide a performant solution is non-trivial. Code written in a query expression must be analyzed and converted to an equivalent database query format. It is not necessary for all code in a native query to be translated. If the optimizer cannot handle some or all code in a query expression, there always is the fallback to instantiate the actual objects and to run the query expression code, or part of it, with real objects after the query has returned intermediate values. Because this may be slow, it will be helpful to provide developers with feedback at development time. This feedback might include how the optimizer \understands” query expressions, and some description of the underlying optimization plan created for the expressions. This will help developers to adjust their development style to the syntax that is optimized best and will enable developers to provide feedback about desirable improved optimizations.
Download file here
