>From Shahrzad Shirazi <[email protected]>: Attention is currently required from: Ali Alsuliman, Peeyush Gupta.
Shahrzad Shirazi has posted comments on this change by Shahrzad Shirazi. ( https://asterix-gerrit.ics.uci.edu/c/asterixdb/+/20774?usp=email ) Change subject: [ASTERIXDB-3688][COMP] Improving Index Selection for Index-Only Query Plans ...................................................................... Patch Set 16: (2 comments) File asterixdb/asterix-algebra/src/main/java/org/apache/asterix/optimizer/rules/am/IntroduceSelectAccessMethodRule.java: https://asterix-gerrit.ics.uci.edu/c/asterixdb/+/20774/comment/cc8d6183_4aef6fe2?usp=email : PS11, Line 425: if (coversAllI && !coversAllJ) { : // Smaller prefix covers all, keep it, remove larger : include[j] = false; > I am not sure if this resolves Ali's earlier point. For example consider a > query on collection1 […] So for the case you mentioned,we are not throwing away (both the way that we had it before and we have it now) as the indexes do not have the same prefix (same list and same order) and they are not both covering. So we will keep both indexes and CBO can decide what to do. So we would have "intersecting the indexes for all cases" without the CBO. With CBO: CBO can decide which one to pick. File asterixdb/asterix-algebra/src/main/java/org/apache/asterix/optimizer/rules/am/IntroduceSelectAccessMethodRule.java: https://asterix-gerrit.ics.uci.edu/c/asterixdb/+/20774/comment/24410845_bb0e1df7?usp=email : PS16, Line 423: if (numJ > numI) { This was added because previously we were returning only one index per type. As a result, if we had two indexes,index1(a, b) and index2(a, b, c),only the first one would be returned. With a small change in AbstractIntroduceAccessMethodRule for B-trees and R-trees, we now return all applicable indexes. Without this check, the code would incorrectly discard index2, even though it might be useful. With this check in place, we discard an index only when it is a strict superset of another index and the smaller index is its prefix, and the larger index does not contribute any additional benefit for the query. Discarding such indexes is necessary to avoid plans with unwanted intersects. It’s worth noting that this logic applies only when both indexes have the same type and prefix, and the larger index does not cover any additional fields relevant to the query. In these cases, keeping the larger index is not beneficial for either CBO or RBO. -- To view, visit https://asterix-gerrit.ics.uci.edu/c/asterixdb/+/20774?usp=email To unsubscribe, or for help writing mail filters, visit https://asterix-gerrit.ics.uci.edu/settings?usp=email Gerrit-MessageType: comment Gerrit-Project: asterixdb Gerrit-Branch: master Gerrit-Change-Id: I4f996ee7b6eb03067fb384161fb4eb60f94e8353 Gerrit-Change-Number: 20774 Gerrit-PatchSet: 16 Gerrit-Owner: Shahrzad Shirazi <[email protected]> Gerrit-Reviewer: Ali Alsuliman <[email protected]> Gerrit-Reviewer: Anon. E. Moose #1000171 Gerrit-Reviewer: Jenkins <[email protected]> Gerrit-Reviewer: Peeyush Gupta <[email protected]> Gerrit-Reviewer: Preetham Poluparthi <[email protected]> Gerrit-Attention: Peeyush Gupta <[email protected]> Gerrit-Attention: Ali Alsuliman <[email protected]> Gerrit-Comment-Date: Mon, 26 Jan 2026 17:56:13 +0000 Gerrit-HasComments: Yes Gerrit-Has-Labels: No Comment-In-Reply-To: Peeyush Gupta <[email protected]>
