DB2 UDB for z/OS Version 8 Performance Topics - IBM Redbooks

Increase of BIND cost
BIND cost for query
(select count(*)...)
without MQT is 0.01 s
BIND cost for query
using one MQT is
0.015 s
Roughly 0.4 ms to
examine each
qualified MQT
Figure 3-10 Increase of BIND cost
We have run Explain for a simple query with varying number of MQTs (0, 1, 5, 10, 20, 30, and
40) eligible for query rewrite. All MQTs are created the same except for the literal value in
predicates. All MQTs are evaluated as possible candidates for query rewrite.
We see that bind cost in CPU increases almost linearly as more and more MQTs are eligible
for query rewrite.
Query rewrite for a simple query
Figure 3-11 reports the performance of a query rewrite for a simple query.
This query selects the count of the number of rows grouped by column BRN for those values
of BRNs that have more than 50 rows. In V7, DB2 has to scan all rows from the source table
(one million rows). The plan table indicates a table space scan for table EVE. DB2 V7 could
decrease the elapsed type if parallelism is enabled. With parallelism the elapsed time is
smaller but there is a small increase in CPU time due to the parallelism overhead.
When executing the same query in V8, the automatic query rewrite is done by the optimizer
selecting the MQT named MQT091. This fact is reflected in the plan table showing a table
scan in a smaller table space.
The summary of measurements of query rewrite for a simple query:
► V7 DEGREE(1)
24.77 sec. elapsed time and 4.06 sec. CPU time
► V7 DEGREE(ANY)
6.11 sec. elapsed time and 4.19 sec. CPU time
► V8 using MQT
1.1 sec. elapsed time and 0.06 sec. CPU time
The measurements show that:
CPU Time (sec)
0.035
0.03
0.025
0.02
0.015
0.01
0.005
BIND time
0 1 5 10 20 30 40
Number of MQT
Chapter 3. SQL performance 47