Icon View Incident Report

Serious Serious
Reported By: Wolfgang Klein
Reported On: 5/4/2020
For: Version 2.31 Build 12
# 4778 Query Optimizer Not Calculating I/O Estimates Properly for Upper Bounds of Conditions

There appears to be an optimization issue with the "<" operator when applied to an indexed text field of a select statement.

This condition:

WHERE ("Text" >= '20190919') AND ("Text" < '20190920')

takes 6.7s, whereas the equivalent:

WHERE ("Text" BETWEEN '20190919' AND '20190920') AND ("Text" <> '20190920')

takes only 0s.

Slow:

================================================================================
SQL Query (Executed by EDB 2.31 Build 12)

Note: The SQL  shown here is generated by EDB and may not be exactly the
same as the SQL that was originally entered.  However, none of the differences
alter the execution results in any way.
================================================================================

SELECT ALL
LIST('(' + QUOTEDSTR("ProbenIDNr") + ')') AS "LIST of Expression"
FROM "VProbenTX"
WHERE ("Text" >= '20190919') AND ("Text" < '20190920')

Source Tables
-------------

VProbenTX: 2064037 rows

Result Set
----------

The result set was insensitive and read-only
The result set consisted of one row

Filtering
---------

The following filter condition was applied to the VProbenTX table:

("Text" >= '20190919')

Index scan (IWMMText.TEXT): 60 keys, 8KB estimated cost

AND

("Text" < '20190920')

Row scan with one or more index scans eliminated due to cost (IWMMText): 60
rows, 66,56KB estimated cost

================================================================================
1 row(s) returned in 6,688 secs
================================================================================

Fast:

Execution-Plan:
================================================================================
SQL Query (Executed by EDB 2.31 Build 12)

Note: The SQL  shown here is generated by EDB and may not be exactly the
same as the SQL that was originally entered.  However, none of the differences
alter the execution results in any way.
================================================================================

SELECT ALL
LIST('(' + QUOTEDSTR("ProbenIDNr") + ')') AS "LIST of Expression"
FROM "VProbenTX"
WHERE ("Text" BETWEEN '20190919' AND '20190920') AND ("Text" <> '20190920')

Source Tables
-------------

VProbenTX: 2064037 rows

Result Set
----------

The result set was insensitive and read-only
The result set consisted of one row

Filtering
---------

The following filter condition was applied to the VProbenTX table:

("Text" BETWEEN '20190919' AND '20190920')

Index scan (IWMMText.TEXT): 123 keys, 24KB estimated cost

AND

("Text" <> '20190920')

Row scan with one or more index scans eliminated due to cost (IWMMText): 123
rows, 136,45KB estimated cost

================================================================================
1 row(s) returned in 0 secs
================================================================================



Comments Comments
The issue was with how the query optimizer was calculating the upper estimate bounds for indexed conditions. Instead of using the same calculation method as used elsewhere for other estimate bounds, for the upper estimate bounds the query optimizer would simply use the row count. This would work in the majority of cases, but would cause incorrect total estimates when the index key distribution was skewed heavily towards only a few keys. The fix causes both the lower estimate bound and the upper estimate bound of a condition to be calculated with the same skew, resulting in the avoidance of this bug and more accurate estimates, in general.


Resolution Resolution
Fixed Problem on 5/14/2020 in version 2.31 build 13


Products Affected Products Affected
ElevateDB Additional Software and Utilities
ElevateDB DAC Client-Server
ElevateDB DAC Client-Server with Source
ElevateDB DAC Standard
ElevateDB DAC Standard with Source
ElevateDB DAC Trial
ElevateDB LCL Standard with Source
ElevateDB PHP Standard
ElevateDB PHP Standard with Source
ElevateDB PHP Trial
ElevateDB VCL Client-Server
ElevateDB VCL Client-Server with Source
ElevateDB VCL Standard
ElevateDB VCL Standard with Source
ElevateDB VCL Trial

Image