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

3.7.2 Conclusions
Example 3-9 Multiple table ORDER BY sort query
SELECT C_CUSTKEY, C_NAME,
O_ORDERKEY AS REVENUE,
C_ACCTBAL, C_NAME, C_ADDRESS, C_PHONE, C_COMMENT
FROM CUSTOMER, ORDER
WHERE C_MKTSEGMENT = 'BUILDING'
AND C_CUSTKEY = O_CUSTKEY
AND O_ORDERDATE < DATE('1994-12-05')
ORDER BY C_CUSTKEY, C_NAME,
REVENUE,
C_ACCTBAL, C_NAME, C_ADDRESS, C_PHONE, C_COMMENT
Figure 3-36 shows the performance improvements for ORDER BY due to parallel sort.
Multiple table ORDER BY sort
Figure 3-36 Multiple table order by sort
We observe in the example of ORDER BY the best situation is when we fetch the first 10 rows
(reduction of 81% in elapsed time) when V8 is compared to V7. In this case there is also a
significant reduction in the number of getpages for work files. No merge is needed because
the rows are already in the right sequence.
Parallel sort can improve the elapsed time of long running queries when parallelism is used
as summarized in the following list:
► Up to 6x elapsed time improvement observed with no merge pass
► Typical queries have less improvement due to merge pass
► May need bigger work file buffer pool size
► May need to allocate more work files or use parallel access volume (PAV)
► Work file getpage may increase when query has two or more parallel sort composites
82 DB2 UDB for z/OS Version 8 Performance Topics
ORDER BY sort of 4M rows
nested loop join of 2 tables, 1 parallel group, DEGREE(30)
merge pass not needed for V8, rows already in order by sequence
up to 4.7X reduction in elapsed time
up to 3X reduction in workfile activities
Fetch first 10
Elapsed
rows
secs
CPU
secs
Workfile
getpages
Fetch all rows Elapsed
secs
CPU
secs
Workfile
getpages
V7
Seq Sort
V8
Parallel
Sort
Delta
216 42 -81%
88 74 -16%
1221204 406994 -67%
682 535 -22%
550 557 +1%
1627864 813712 -50%