Hi.
I've created a very small table to illustrate the issue, I'ld like to hear opinions about.
CREATE MULTISET TABLE Table_1
,NO FALLBACK ,
NO BEFORE JOURNAL,
NO AFTER JOURNAL,
CHECKSUM = DEFAULT,
DEFAULT MERGEBLOCKRATIO
(
Textfield CHAR(20) CHARACTER SET LATIN NOT CASESPECIFIC
)
PRIMARY INDEX ( Textfield );
;
I've inserted 10343 records in the table - in total 340 unique values and 381 instances of the value '00001'.
Valueexamples: '00001','02356','47027' etc.
Then I collect stats:
COLLECT STATS ON Table_1 COLUMN (Textfield)
Then some different ways to pick data:
Implicit casting should be performed in the first one, but the Plan calculates the size of the spool to be 6 rows with high confidence. Therefor the query performs catastrophic (not in this little query but in more complicated queries performed on larger tables):
SEL * FROM Table_1
WHERE Textfield = 1
---------
This one works fine because casting is not necessary. The size of the spool is correctly calculated to be 381 rows, and the query performs fine.
SEL * FROM Table_1
WHERE Textfield = '00001'
--------
This one is going wrong to - probably because of the explicit casting - and estimes again the size of the spool to be 6 rows with high confidence with a very poor performance as a result.
SEL * FROM Table_1
WHERE CAST(Textfield AS INTEGER) = 1
All the queries returns the correct result, but there is a very big difference in performance. I would like to know, if You think that this might be an issue with the Optimizer? Personally I have the opinion that the Optimizer should be able to handle the casting better than this.
I am not sure, but it seems that this issue has evolved lately - perhaps after Our latest update of the system to 13.10 from 12.
Is this a known issue?
We are running VERSION 13.10.06.01 - RELEASE 13.10.06.01