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 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. For SQE, view materialization is optional. The following types of queries require view materialization:

  • The outermost view select contains grouping, the query contains grouping, and refers to a column derived from a column function in the view 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. Occurs when a view references a view, and a view composite cannot be created because of one of the previous listed reasons. Does not apply to nested table expressions and common table expressions.
  • The Common table expression (CTE) is referenced more than once in the query FROM clause. Also, the CTE SELECT clause references a MODIFIES or EXTERNAL ACTION UDF.

When a temporary result table is created, access methods that are allowed with ALWCPYDTA(*OPTIMIZE) could 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
Note: The new query that the query optimizer generates is not visible to users. Only the original query against the view is 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 process is not 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