いくつかのシナリオでは、返すことができる最大行よりも大きな値のtotal_rowsフィールドを返すクエリ（明確なlimit、skip、startkeyまたは、endkeyなしのmapビュークエリ）となることが予想されます。

予想されるシナリオはリバランス中で、フェイルオーバ直後の一定期間です。

これらのシナリオでは、いくつかのvbucketsがインデックス内でcleanupとマークされて、一時的にはpassiveとマークされるため、もしくは（フェイルオーバのあと）データがレプリカインデックスからメインインデックスに転送されるため、発生します。それらvbuckets由来の行は問い合わせで返されることは決してありませんが、すべてのビューのbtreeの縮小に関連し、この値はmapビュークエリの応答内のtotal_rowsフィールド（単にビューごとのキーと値のペアの合計数カウンタ）として使われます。

アクティブvbuckets内のドキュメントから発信された行数を常に反映しているtotal_rowsが、とても高価で、大幅にパフォーマンスに影響を与えるということを理解してください。例えば、vbucket IDを行数に対応づけるというbtreeの縮小化の中での異なる値を管理する必要があります。

{"0":56, "1": 2452435, ..., "1023": 432236}

これは、要素をバランスし、それらをもっと深くし、もっとディスクスペースを使用し、そしてinserts/updates/deletesでの計算の縮小のための時間を費やすbtreeをかなり削減します。

クリーンアップ中のvbuckets、passive状態のvbuckets、もしくは(フェイルオーバで)レプリカインデックスからメインインデックスに転送されているvbucketsがあるかどうか知るために、次のURLに問い合せることができます。

shell> curl -s 'http://localhost:9500/_set_view/default/_design/dev_test2/_info' | json_xs
{
   "passive_partitions" : [1, 2, 3],
   "cleanup_partitions" : [],
   "replicas_on_transfer" : [1, 2, 3],
   (....)
}

上記の例では、意図的にすべての非関連フィールドを非表示にしていることに注意してください。上記のいずれかのフィールドが空リストでない場合、ビューのtotal_rowsは予想よりも高くなるでしょう。つまり、上記で言及している予想されたシナリオのひとつとなります。上記のすべての定常状態では、フィールドは空のリストになります。