Support multiple fields; Benchmarks

[nitely]

Benchmark without index; 1M rows; 4 sort fields; page 80K; article 800K:

Offset/Limit 4.610120994999306
Seek Method 0.4367766939994908

Benchmark with index, 1M rows; 4 sort fields; page 80K; article 800K:

Offset/Limit 0.10621846200047003
Seek Method 0.4022486219982966

Benchmark without index; 5M rows; 4 sort fields; page 400K; article 4M:

Offset/Limit 12.005191038999328
Seek Method 3.005880751999939

Benchmark with index; 5M rows; 4 sort fields; page 400K; article 4M:

Offset/Limit 0.591509911000685
Seek Method 2.3944302830004744

It seems the seek method does not use the index, the query may be just too complex 😕 . It doesn't seem to be a way to query with row values, so I cannot make it more efficient. Even with just 2 fields the index is not use in my benchmark, at least.

Update:

Oh, I found my answer here:

The where clause consists of two parts. The first part considers the SALE_DATE only and uses a less than or equal to (<=) condition—it selects more rows as needed. This part of the where clause is simple enough so that all databases can use it to access the index.

So, my benchmark is an edge case, possibly. The first filtered value is the same for all rows, so the index is not used. When testing two fields I filtered by a duplicated date, and when testing 4 fields I filtered by a boolean. Albeit, a boolean as first field seems common.

Benchmark with index, 1M rows; 1 sort fields; page 80K; article 800K:

Offset/Limit 0.10032956400027615
Seek Method 0.0016662500020174775

Indeed, when testing a single field (ex a unique field), the index is used, and the query is fast. So, the answer is maybe somehow implement the row values query if I want this to be fast for more cases.

[coveralls]

Coverage increased (+0.1%) to 95.644% when pulling 6c0a509 on multi_fields into 52576bc on master.