Bug#16540042: WRONG QUERY RESULT WHEN USING RANGE OVER

              PARTIAL INDEX

Consider the following table definition:

CREATE TABLE t (
  my_col CHAR(10),
  ...
  INDEX my_idx (my_col(1))
)

The my_idx index is not able to distinguish between rows with
equal first-character my_col-values (e.g. "f", "foo", "fee").

Prior to this CS, the range optimizer would translate

"WHERE my_col NOT IN ('f', 'h')" into (optimizer trace syntax)

"ranges": [
  "NULL < my_col < f",
  "f < my_col"
]

But this was not correct because the rows with values "foo" 
and "fee" would not belong to any of those ranges. However, the
predicate "my_col != 'f' AND my_col != 'h'" would translate
to 

"ranges": [
  "NULL < my_col"
]

because get_mm_leaf() changes from "<" to "<=" for partial
keyparts. This CS changes the range optimizer implementation 
for NOT IN to behave like a conjunction of NOT EQUAL: it 
replaces "<" with "<=" for all but the first range when the
keypart is partial.

0 files changed, 0 insertions, 0 deletions