I bound my package with EXPLAIN(YES), and it's got the following static
SQL in it:
EXEC SQL SELECT CARDF, RECLENGTH
INTO :CARDF,:RECLENGTH
FROM SYSIBM.SYSTABLES
WHERE NAME = :TBNAME
AND CREATOR = :TBCREATOR
The explain shows that it does a *full table scan* on SYSIBM.SYSTABLES!
And the execution time seems to show that is what it is doing, it
takes about 3 seconds to get this 1 row executing this static SQL.
Using Visual Explain and putting in:
SELECT CARDF, RECLENGTH FROM SYSIBM.SYSTABLES
WHERE NAME = 'X' AND CREATOR = 'Y'
or:
SELECT CARDF, RECLENGTH FROM SYSIBM.SYSTABLES
WHERE NAME = ? AND CREATOR = ?
Both show an index scan (IXSCAN) to get the one row answer.
What is going on here? How could the query optimizer *not* be deciding
to use the primary key on CREATOR and NAME?
Here are some details to help:
1. DB2 7.1 on z/OS
2. Code written in C
2. bind variable TBCREATOR null terminated, defined as:
char TBCREATOR[9];
3. bind variable TBNAME is a VARCHAR type:
struct
{ short int TBNAME_len;
char TBNAME_data[18];
} TBNAME;
4. DB2 defines SYSIBM.SYSTABLES with a primary key on CREATOR and NAME
5. I have not gathered stats (RUNSTATS) on SYSIBM.SYSTABLES, so the
stats are all defaults (-1) on both the table and its indexes.
Any help would be appreciated.
- Gorilla