IBM Support

IV33576: OPTIMIZER MIGHT FAVOUR HSJOIN OVER AN ORDERED NLJOIN

Subscribe

You can track all active APARs for this component.

 

APAR status

  • Closed as fixed if next.

Error description

  • The optimizer might favour a hash join (HSJOIN) over a nested
    loop join (NLJOIN) alternative under the following conditions:
    - the join is on two or more columns
    - both tables in the join have an index with leading, non-bound
    key columns that participate in the join
    - one or more leading columns match in order of the join
    columns, but not all
    
    For example, consider the following query
    
    SELECT *
    FROM T1,T2
    WHERE T1.A=T2.A and T1.B=T2.B and T1.C=T2.C and T1.X=1;
    
    where index IX1 is defined on T1(X,A,C,B) and index IX2 is
    defined on T2(A,B,C).  The column T1.X is bound to the constant
    1 as a result of the predicate "T1.X=1" so for the NLJOIN with
    IX1 access on the outer and IX2 access on the inner, the leading
    non-bound columns for both indexes are referenced in the join
    predicate T1.A=T2.A, but the subsequent columns are not ordered
    in join column order.  Under these conditions, the optimizer
    might over estimate the cost of the NLJOIN alternative,
    favouring a possibly worse-performing HSJOIN alternative
    

Local fix

  • Create an index on either table, ensuring that the key columns
    are in join order.  Referring to the example in the Error
    Description, this could be achieved by creating an index on
    T2(A,C,B).
    

Problem summary

  • ****************************************************************
    * USERS AFFECTED:                                              *
    * ALL                                                          *
    ****************************************************************
    * PROBLEM DESCRIPTION:                                         *
    * See Error Description                                        *
    ****************************************************************
    * RECOMMENDATION:                                              *
    * Upgrade to the level of DB2 Version 9.7 containing fix for   *
    * APAR IC90024                                                 *
    ****************************************************************
    

Problem conclusion

Temporary fix

  • See Local Fix
    

Comments

APAR Information

  • APAR number

    IV33576

  • Reported component name

    DB2 POFW

  • Reported component ID

    5724N8100

  • Reported release

    950

  • Status

    CLOSED FIN

  • PE

    NoPE

  • HIPER

    NoHIPER

  • Special Attention

    NoSpecatt

  • Submitted date

    2012-12-17

  • Closed date

    2013-02-05

  • Last modified date

    2013-02-05

  • APAR is sysrouted FROM one or more of the following:

  • APAR is sysrouted TO one or more of the following:

    IC90024

Fix information

Applicable component levels

  • R950 PSN

       UP

[{"Business Unit":{"code":"BU058","label":"IBM Infrastructure w\/TPS"},"Product":{"code":"SSEPGG","label":"Db2 for Linux, UNIX and Windows"},"Component":"","ARM Category":[],"Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"950","Edition":"","Line of Business":{"code":"LOB10","label":"Data and AI"}}]

Document Information

Modified date:
05 February 2013