Hi Wayne, While CI2 with stale=false is lower than Q2, the numbers are >30% better than 4.1 (5005) release. So, this has actually improved significantly.
Of course Q2(stale=false) has improved compared 4.1, albeit at a slightly better rate.

I'll ask secondary index & forstdb teams to look at it as well.

IMO, for measuring covering index, we should use stale=ok test. This will stress out the code path in indexer and cbq more. Stale=false is mostly depends on storage write throughput, so it is not a good indication of effectiveness of covering index (read throughput)

For stale=ok, CI2 and Q2 are about the same. But CI3 throughput is twice of Q3. This clearly shows covering index can yield better performance in typical use case (with larger row count).

The stale=false with forestdb is in reasonable range. I'm closing this issue now as we don't intend to do additional work improve this. The work on lightweight snapshot may improve this number.

Bulk closing invalid bugs