From df986362a47fa9c3e9243e5c5de2153889d2f103 Mon Sep 17 00:00:00 2001 From: "Brian S. O'Neill" Date: Fri, 19 Jan 2007 00:42:05 +0000 Subject: Added additional index selection tie-breaker if index is most likely defined to support desired ordering. --- RELEASE-NOTES.txt | 7 +++++++ src/main/java/com/amazon/carbonado/qe/CompositeScore.java | 14 ++++++++++++-- 2 files changed, 19 insertions(+), 2 deletions(-) diff --git a/RELEASE-NOTES.txt b/RELEASE-NOTES.txt index 5f6379f..b5411c2 100644 --- a/RELEASE-NOTES.txt +++ b/RELEASE-NOTES.txt @@ -1,6 +1,13 @@ Carbonado change history ------------------------ +1.1-BETA9 to 1.1-BETA10 +------------------------------- +- JDBCSupportStrategy cleans up database product name before using it to + determine custom support strategy class name. +- Added additional index selection tie-breaker if index is most likely defined + to support desired ordering. + 1.1-BETA8 to 1.1-BETA9 ------------------------------- - Fixed bug in JDBC repository which caused cursor skip to skip everything. diff --git a/src/main/java/com/amazon/carbonado/qe/CompositeScore.java b/src/main/java/com/amazon/carbonado/qe/CompositeScore.java index 9992690..e031fe2 100644 --- a/src/main/java/com/amazon/carbonado/qe/CompositeScore.java +++ b/src/main/java/com/amazon/carbonado/qe/CompositeScore.java @@ -224,8 +224,18 @@ public class CompositeScore { return preferenceResult; } - // Preference scores are the same? That seems unlikely, but - // choose the better filtering index. + // Okay, preference is not helping. If handled filter count is + // the same, choose the better ordering. Why? Most likely a nearly + // identical index was created specifically for ordering. One index + // might look better for filtering just because it is clustered. + + if (firstScore.getHandledCount() == secondScore.getHandledCount()) { + if (handledScore != 0) { + return handledScore; + } + } + + // Just return the result for the better filtering index. return result; } -- cgit v1.2.3