The key to performance is looking for the new CQT operator in the query access plans (explain output). A usage example is shown here in the DB2 Information Center:
Access Plan:
-----------
Total Cost: 570246
Query Degree: 32
Rows
RETURN
( 1)
Cost
I/O
|
191
LTQ
( 2)
570246
505856
|
191
CTQ
( 3)
570245
505856
|
191
GRPBY
( 4)
570245
505856
|
2.87997e+08
^HSJOIN
( 5)
377881
505856
/-----+------\
2.87997e+08 2e+06
TBSCAN TBSCAN
( 6) ( 7)
329484 4080.56
499008 6848
| |
2.87997e+08 2e+06
CO-TABLE: TPCDS CO-TABLE: TPCDS
STORE_SALES CUSTOMER
Q1 Q2
But what is the operator CTQ and what does CTQ stand for? Is it "Critical To Quality", "Copy The Query", "Come on, Tune the Query"or "Critical To Quickness"? TQs are so-called Table Queue operators and are used to pass a special result set from A to B. They are often seen in partitioned databases (InfoSphere Warehouse) as either Directed Table Queues (DTQs) or Broadcast Table Queue (BTQs) to move data across nodes in the cluster. For BLU Acceleration a CTQ is the "columnar to row" gatekeeper and means that the world of BLU has been left and regular DB2 technology takes over.
Ideally, there is only a single CTQ in a query plan and high up because this would mean (almost) everything is processed with BLU Acceleration. If you only store some tables in columnar format, other tables in classic row organization (remember: DB2 with BLU Acceleration is hybrid) and see many CTQs in an access plan and only near the bottom of the plan, rethinking the strategy for the physical database design might be a good idea.
Come on, Tune the Queries - of course with DB2 and BLU Acceleration...