DB2 - Problem description
| Problem IC63295 | Status: Closed |
IMPROVEMENT ON PROCESSING FETCH FIRST N ROWS IN DPF ENVIRONMENT | |
| product: | |
DB2 FOR LUW / DB2FORLUW / 970 - DB2 | |
| Problem description: | |
In DPF environment, DB2 optimizer always generates an access
plan for the FETCH FIRST N ROWS clause by sending data to a
coordinator node and fetch the first N rows of the data.
This can cause performance degradation and in the access plan of
the query using FETCH FIRST N ROWS, we can see redundant TQ.
Rows
RETURN
( 1)
Cost
I/O
|
50000
DELETE
( 2)
768333
134645
/----+----\
50000 9.3116e+06
FETCH DP-TABLE: TABLE1
( 3)
390
84645
/----+-----\
50000 9.3116e+06
DTQ DP-TABLE: TABLE1
( 4)
12152.9
34645
|
1e+06
DTQ
( 5)
12088.6
34645
|
804913
TBSCAN
( 6)
11979.4
34645
|
9.3116e+06
DP-TABLE: TABLE1
This work detects cases where data are from a single node and
being applied the FETCH FIRST N ROWS clause. DB2 optimizer will,
instead of moving the data to a coordinator node, locally fetch
the first N rows from the node the date reside.
Example:
DELETE FROM (SELECT * FROM TABLE1 T WHERE DBPARTITIONNUM(T.C1) =
1 FETCH FIRST 10 ROWS ONLY);
DB2 optimizer will fetch the first 10 rows from table TABLE1 at
database partition number 1 and send the 10 rows to the DELETE
operation locally in the same database partition. | |
| Problem Summary: | |
IMPROVEMENT ON PROCESSING FETCH FIRST N ROWS IN DPF ENVIRONMENT | |
| Local Fix: | |
| available fix packs: | |
DB2 Version 9.7 Fix Pack 3 for Linux, UNIX, and Windows | |
| Solution | |
Fixed in DB2 v97FP3 | |
| Workaround | |
not known / see Local fix | |
| Timestamps | |
Date - problem reported : Date - problem closed : Date - last modified : | 21.09.2009 29.09.2010 29.09.2010 |
| Problem solved at the following versions (IBM BugInfos) | |
9.7.FP3 | |
| Problem solved according to the fixlist(s) of the following version(s) | |
| 9.7.0.3 |
|
| 9.7.0.3 |
|