summaryrefslogtreecommitdiff
path: root/jstests/ori.js
blob: 03dead5c92424edf3b1a0dc3df98a38c74ceec62 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
// Check elimination of proper range type when popping a $or clause SERVER-958.

t = db.jstests_ori;
t.drop();

t.ensureIndex( {a:1,b:1} );
t.ensureIndex( {a:1,c:1} );

t.save( {a:1,b:[2,3],c:4} );
t.save( {a:10,b:2,c:4} );

// Check that proper results are returned.

assert.eq( 2, t.count( {$or:[{a:{$gt:0,$lt:5},b:2},{a:10,c:4}]} ) );
// Two $or clauses expected to be scanned.

// QUERY_MIGRATION: we may merge sort these
//assert.eq( 2, t.find( {$or:[{a:{$gt:0,$lt:5},b:2},{a:10,c:4}]} ).explain().clauses.length );
assert.eq( 2, t.count( {$or:[{a:10,b:2},{a:{$gt:0,$lt:5},c:4}]} ) );

t.drop();

// Now try a different index order.

t.ensureIndex( {b:1,a:1} );
t.ensureIndex( {a:1,c:1} );

t.save( {a:1,b:[2,3],c:4} );
t.save( {a:10,b:2,c:4} );

assert.eq( 2, t.count( {$or:[{a:{$gt:0,$lt:5},b:2},{a:10,c:4}]} ) );
assert.eq( 2, t.count( {$or:[{a:10,b:2},{a:{$gt:0,$lt:5},c:4}]} ) );

t.drop();

// Now eliminate a range.

t.ensureIndex( {a:1} );
t.ensureIndex( {b:1} );

t.save( {a:[1,2],b:1} );
t.save( {a:10,b:1} );

assert.eq( 2, t.count( {$or:[{a:{$gt:0,$lt:5}},{a:10,b:1}]} ) );
// Because a:1 is multikey, the value a:10 is scanned with the first clause.
assert.isnull( t.find( {$or:[{a:{$gt:0,$lt:5}},{a:10,b:1}]} ).explain().clauses );

assert.eq( 2, t.count( {$or:[{a:{$lt:5,$gt:0}},{a:10,b:1}]} ) );
// Now a:10 is not scanned in the first clause so the second clause is not eliminated.

// QUERY MIGRATION
// This is worth investigating. Execution is choosing a collection scan over the or over
// over index plans
// printjson( t.find( {$or:[{a:{$lt:5,$gt:0}},{a:10,b:1}]} ).explain() )
// assert.eq( 2, t.find( {$or:[{a:{$lt:5,$gt:0}},{a:10,b:1}]} ).explain().clauses.length );