View materialization implementation

 

The view materialization implementation runs the query of the view and places the results in a temporary result. The view reference in the user's query is then replaced with the temporary, and the query is run against the temporary result.

View materialization is done whenever it is not possible to create a view composite. Note that for SQE, view materialization is optional. The following types of queries require view materialization:

• The outermost select of the view contains grouping, the query contains grouping, and refers to a column derived from a column function in the view in the HAVING or select-list.

• The query is a join and the outermost select of the view contains grouping or DISTINCT.

• The outermost select of the view contains DISTINCT, and the query has UNION, grouping, or DISTINCT and one of the following:

  • Only the query has a shared weight NLSS table

  • Only the view has a shared weight NLSS table

  • Both the query and the view have a shared weight NLSS table, but the tables are different.

• The query contains a column function and the outermost select of the view contains a DISTINCT

• The view does not contain an access plan. This can occur when a view references a view and a view composite cannot be created because of one of the reasons listed above. This does not apply to nested table expressions and common table expressions.

• The Common table expression (CTE) is reference more than once in the query's FROM clause(s) and the CTE's SELECT clause references a MODIFIES or EXTERNAL ACTION UDF.

When a temporary result table is created, access methods that are allowed with ALWCPYDTA(*OPTIMIZE) may be used to implement the query. These methods include hash grouping, hash join, and bitmaps.

See the following examples:

CREATE VIEW AVGSALVW AS
  SELECT WORKDEPT, AVG(SALARY) AS AVGSAL   FROM CORPDATA.EMPLOYEE   GROUP BY WORKDEPT

SQL example:

  SELECT D.DEPTNAME, A.AVGSAL   FROM CORPDATA.DEPARTMENT D, AVGSALVW A   WHERE D.DEPTNO=A.WORKDEPT

In this case, a view composite cannot be created since a join query references a grouping view. The results of AVGSALVW are placed in a temporary result table (*QUERY0001). The view reference AVGSALVW is replaced with the temporary result table. The new query is then run. The generated query looks like the following:

SELECT D.DEPTNAME, A.AVGSAL   FROM CORPDATA.DEPARTMENT D, *QUERY0001 A   WHERE D.DEPTNO=A.WORKDEPT

The new query that the query optimizer generates is not visible to users. Only the original query against the view will be seen by users and database performance tools.

Whenever possible, isolatable selection from the query, except subquery predicates, is added to the view materialization process. This results in smaller temporary result tables and allows existing indexes to be used when materializing the view. This will not be done if there is more than one reference to the same view or common table expression in the query. The following is an example where isolatable selection is added to the view materialization:

SELECT D.DEPTNAME,A.AVGSAL 	
  FROM CORPDATA.DEPARTMENT D, AVGSALVW A   WHERE D.DEPTNO=A.WORKDEPT AND
  A.WORKDEPT LIKE 'D%' AND AVGSAL>10000

The isolatable selection from the query is added to the view resulting in a new query to generate the temporary result table:

SELECT WORKDEPT, AVG(SALARY) AS AVGSAL   FROM CORPDATA.EMPLOYEE   WHERE WORKDEPT LIKE 'D%'
  GROUP BY WORKDEPT   HAVING AVG(SALARY)>10000      

 

Parent topic:

View implementation