![]() |
Internal Language Transformations
|
Reference Manual |
View TransformationsWhen Cloudscape evaluates a statement that references a view, it transforms the reference to a view into a derived table. It may make additional transformations to improve performance. View FlatteningWhen evaluating a statement that references a view, Cloudscape internally transforms a view into a derived table. This derived table may also be a candidate for flattening into the outer query block. A view or derived table can be flattened into the outer query block if all of the following conditions are met:
For example, given view v1(a,b):
SELECT Hotels.hotel_name, Cities.city_id and a SELECT that references it:
SELECT a, b after the view is transformed into a derived table, the internal query is
SELECT a, b After view flattening it becomes
SELECT Hotels.hotel_name as a, Cities.city_id AS b Predicates Pushed into Views or Derived TablesAn SQL-J statement that references a view may also include a predicate. Consider the view v2 (a,b):
CREATE VIEW v2(a,b) AS The following statement references the view and includes a predicate: When Cloudscape transforms that statement by first transforming the view into a derived table, it places the predicate at the top level of the new query, outside the scope of the derived table:
SELECT a, b In the example in the preceding section (see View Flattening), Cloudscape was able to flatten the derived table into the main SELECT, so the predicate in the outer SELECT could be evaluated at a useful point in the query. This is not possible in this example, because the underlying view does not satisfy all the requirements of view flattening. However, if the source of all of the column references in a predicate is a simple column reference in the underlying view or table, Cloudscape is able to push the predicate down to the underlying view. Pushing down means that the qualification described by the predicate can be evaluated when evaluating the view is being evaluated, which is more efficient. In our example, the column reference in the outer predicate, a, in the underlying view is a simple column reference to the underlying base table. So the final transformation of this statement after predicate push-down is
SELECT a, b Without the transformation, Cloudscape would have to scan the entire table t1 to form all the groups, only to throw out all but one of the groups. With the transformation, Cloudscape is able to make that qualification part of the derived table. If there were a predicate that referenced column b, it could not be pushed down, because in the underlying view, column b is not a simple column reference. Predicate push-down transformation includes predicates that reference multiple tables from an underlying join. |
|
![]() Cloudscape Version 3.6 For information about Cloudscape technical support, go to: www.cloudscape.com/support/.Copyright © 1998, 1999, 2000 Informix Software, Inc. All rights reserved. |