[SERVER-3187] keymatch optimizations, in particular for negative predicates Created: 03/Jun/11  Updated: 10/Dec/14  Resolved: 06/Jan/14

Status: Closed
Project: Core Server
Component/s: Index Maintenance
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Major - P3
Reporter: Aaron Staple Assignee: Unassigned
Resolution: Done Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Duplicate
is duplicated by SERVER-8549 Not in covered index query does not h... Closed
is duplicated by SERVER-8551 Exists query with a sparse index shou... Closed
Participants:

 Description   

There are some optimizations we can make to cases where we currently limit key matching. In some cases a match is possible with a single key index while not with multikey, in some cases a match can be a keymatch based on the value being compared (for example if it is a non null value), and there are some other things we can do too.

Matcher::Matcher( const Matcher &other, const BSONObj &key ) :
where(0), constrainIndexKey_( key ), haveSize(), all(), hasArray(0), haveNeg(), _atomic(false), nRegex(0) {
// do not include field matches which would make keyMatch() false
for( vector< ElementMatcher >::const_iterator i = other.basics.begin(); i != other.basics.end(); ++i ) {
if ( key.hasField( i->toMatch.fieldName() ) ) {
switch( i->compareOp ) {
case BSONObj::opSIZE:
case BSONObj::opALL:
case BSONObj::NE:
case BSONObj::NIN:
case BSONObj::opEXISTS: // Not part of keyMatch() determination, but we can't match on index in this case.
case BSONObj::opTYPE: // For $type:10 (null), a null key could be a missing field or a null value field.



 Comments   
Comment by David Storch [ 06/Jan/14 ]

Resolving as "Gone Away" because I believe that this ticket is describing improvements to dead code.

Generated at Thu Feb 08 03:02:20 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.