<!-- 
RSS generated by JIRA (9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66) at Thu Feb 08 02:57:55 UTC 2024

It is possible to restrict the fields that are returned in this document by specifying the 'field' parameter in your request.
For example, to request only the issue key and summary append 'field=key&field=summary' to the URL of your request.
-->
<rss version="0.92" >
<channel>
    <title>MongoDB Jira</title>
    <link>https://jira.mongodb.org</link>
    <description>This file is an XML representation of an issue</description>
    <language>en-us</language>    <build-info>
        <version>9.7.1</version>
        <build-number>970001</build-number>
        <build-date>13-04-2023</build-date>
    </build-info>


<item>
            <title>[SERVER-1752] improve the performance of simple counts</title>
                <link>https://jira.mongodb.org/browse/SERVER-1752</link>
                <project id="10000" key="SERVER">Core Server</project>
                    <description>&lt;p&gt;Summary:&lt;/p&gt;

&lt;p&gt;Two optimizations have been implemented for the count operation:&lt;/p&gt;

&lt;p&gt;1) Normally, when documents are retrieved from an indexed Cursor, the index key and/or document at each position of the cursor are checked by a Matcher to see if they match the query.  As an optimization, this Matcher check is now bypassed in simple cases when the documents iterated by the Cursor must always match the query.  Specifically, if an &apos;Optimal&apos; btree index is used to perform a count, and the index bounds for the count&apos;s query spec on that index are determined to exactly describe the documents that match the query, then a Matcher is not used.  An explain( true ) on a find with the same query spec as the count will generally indicate if an &apos;Optimal&apos; index is used (generally the case if there is only one btree plan in allPlans) and will show the indexBounds on the index.&lt;/p&gt;

&lt;p&gt;2) Normally, when a btree cursor iterates over keys in a btree, the cursor checks every key traversed to see if it falls within the calculated indexBounds.  As an optimization, this key check is now bypassed in simple cases where the iteration endpoint can be precomputed.  Specifically, if an &apos;Optimal&apos; btree index is used to perform a count, and the indexBounds describe a single interval within the btree, then the endpoint of that interval is located in advance so that the traversed keys do not need to be individually checked for inclusion in the interval.  An explain( true ) of an optimal index will generally indicate usage of a single interval when the cursor explain field does not have a &quot;multi&quot; suffix.&lt;/p&gt;

&lt;p&gt;Aaron&lt;/p&gt;

&lt;p&gt;---------------------------------&lt;/p&gt;

&lt;p&gt;The count performance is so pool that we can not use it,if the client must wait 5000 millis for every count request,they will be unhappy!&lt;br/&gt;
db.Comment.count() done quickly,but db.Comment.count(&lt;/p&gt;
{appId:1,topicId:1}
&lt;p&gt;) need so much more time.&lt;br/&gt;
I use mongo 1.7.0:&lt;br/&gt;
{&lt;br/&gt;
       &quot;cursor&quot; : &quot;BtreeCursor appId_1_topicId_1&quot;,&lt;br/&gt;
       &quot;nscanned&quot; : 2101980,&lt;br/&gt;
       &quot;nscannedObjects&quot; : 2101980,&lt;br/&gt;
       &quot;n&quot; : 2101980,&lt;br/&gt;
       &quot;millis&quot; : 4677,&lt;br/&gt;
       &quot;indexBounds&quot; : &lt;/p&gt;
{
               &quot;appId&quot; : [
                       [
                               1,
                               1
                       ]
               ],
               &quot;topicId&quot; : [
                       [
                               103,
                               103
                       ]
               ]
       }
&lt;p&gt;}&lt;/p&gt;

&lt;p&gt;a simple count will need 4677ms,if the result is smaller,eg 51140 but not 2101980,the count query will done less than 200ms!&lt;br/&gt;
{&lt;br/&gt;
        &quot;cursor&quot; : &quot;BtreeCursor appId_1_topicId_1&quot;,&lt;br/&gt;
        &quot;nscanned&quot; : 51140,&lt;br/&gt;
        &quot;nscannedObjects&quot; : 51140,&lt;br/&gt;
        &quot;n&quot; : 51140,&lt;br/&gt;
        &quot;millis&quot; : 108,&lt;br/&gt;
        &quot;indexBounds&quot; : &lt;/p&gt;
{
                &quot;appId&quot; : [
                        [
                                1,
                                1
                        ]
                ],
                &quot;topicId&quot; : [
                        [
                                1,
                                1
                        ]
                ]
        }
&lt;p&gt;}&lt;/p&gt;

&lt;p&gt;the count() can not use explain(),so I use db.Comment.find(&lt;/p&gt;
{appId:1,topicId:1}
&lt;p&gt;).explain(),but the result maybe the same.&lt;/p&gt;</description>
                <environment>Linux</environment>
        <key id="13036">SERVER-1752</key>
            <summary>improve the performance of simple counts</summary>
                <type id="4" iconUrl="https://jira.mongodb.org/secure/viewavatar?size=xsmall&amp;avatarId=14710&amp;avatarType=issuetype">Improvement</type>
                                            <priority id="3" iconUrl="https://jira.mongodb.org/images/icons/priorities/major.svg">Major - P3</priority>
                        <status id="6" iconUrl="https://jira.mongodb.org/images/icons/statuses/closed.png" description="The issue is considered finished, the resolution is correct. Issues which are closed can be reopened.">Closed</status>
                    <statusCategory id="3" key="done" colorName="success"/>
                                    <resolution id="9">Done</resolution>
                                        <assignee username="aaron">Aaron Staple</assignee>
                                    <reporter username="phoenix">phoenix</reporter>
                        <labels>
                    </labels>
                <created>Wed, 8 Sep 2010 01:03:14 +0000</created>
                <updated>Wed, 28 Oct 2015 16:21:28 +0000</updated>
                            <resolved>Fri, 21 Dec 2012 04:22:51 +0000</resolved>
                                    <version>1.7.0</version>
                                    <fixVersion>2.3.2</fixVersion>
                                    <component>Performance</component>
                                        <votes>133</votes>
                                    <watches>118</watches>
                                                                                                                <comments>
                            <comment id="221040" author="eliot" created="Fri, 21 Dec 2012 05:26:54 +0000"  >&lt;p&gt;Jon - thanks, forgot about that message, updated.&lt;/p&gt;</comment>
                            <comment id="221037" author="jonhyman" created="Fri, 21 Dec 2012 05:24:21 +0000"  >&lt;p&gt;Okay, thanks for the update. In general, you should update the &quot;We aim to do a stable release every 3 months&quot; tag on jira. 2.2 came out almost a year after 2.0, so I was worried that 2.4 was going to be far into the future.&lt;/p&gt;</comment>
                            <comment id="221014" author="eliot" created="Fri, 21 Dec 2012 04:56:53 +0000"  >&lt;p&gt;Jon - no, unfortunately a change like this is not back portable as its relatively large, and stability on 2.2 is paramount.  &lt;br/&gt;
2.4 should be in Q1 of 2013, the dev cycle for it is wrapping up in the next couple of weeks.&lt;/p&gt;</comment>
                            <comment id="220993" author="jonhyman" created="Fri, 21 Dec 2012 04:28:36 +0000"  >&lt;p&gt;Is there any way this could be backported into a 2.2.x build? Without a clear understanding of the 2.4 release timeframe (since it&apos;s not on the roadmap AFAICT), we would really benefit from this right now. While we&apos;ve precomputed a great deal of queries we otherwise would have used count() for, some of our count queries are hard to precompute and take a long time.&lt;/p&gt;</comment>
                            <comment id="194619" author="auto" created="Tue, 20 Nov 2012 10:40:19 +0000"  >&lt;p&gt;Author:&lt;/p&gt;
{u&apos;date&apos;: u&apos;2012-11-20T10:36:10Z&apos;, u&apos;email&apos;: u&apos;aaron@10gen.com&apos;, u&apos;name&apos;: u&apos;Aaron&apos;}
&lt;p&gt;Message: &lt;a href=&quot;https://jira.mongodb.org/browse/SERVER-1752&quot; title=&quot;improve the performance of simple counts&quot; class=&quot;issue-link&quot; data-issue-key=&quot;SERVER-1752&quot;&gt;&lt;del&gt;SERVER-1752&lt;/del&gt;&lt;/a&gt; Fix debug build tests by removing old imprecise dassert in BtreeBucket56Bit.&lt;br/&gt;
Branch: master&lt;br/&gt;
&lt;a href=&quot;https://github.com/mongodb/mongo/commit/08cfe5f5054eff0830c12289c38e7c49460ce86d&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;https://github.com/mongodb/mongo/commit/08cfe5f5054eff0830c12289c38e7c49460ce86d&lt;/a&gt;&lt;/p&gt;</comment>
                            <comment id="194425" author="auto" created="Tue, 20 Nov 2012 04:45:20 +0000"  >&lt;p&gt;Author:&lt;/p&gt;
{u&apos;date&apos;: u&apos;2012-11-20T04:45:09Z&apos;, u&apos;email&apos;: u&apos;aaron@10gen.com&apos;, u&apos;name&apos;: u&apos;Aaron&apos;}
&lt;p&gt;Message: &lt;a href=&quot;https://jira.mongodb.org/browse/SERVER-1752&quot; title=&quot;improve the performance of simple counts&quot; class=&quot;issue-link&quot; data-issue-key=&quot;SERVER-1752&quot;&gt;&lt;del&gt;SERVER-1752&lt;/del&gt;&lt;/a&gt; Fix rhel compile by including pdfile.h for inlined btree() implementation.&lt;br/&gt;
Branch: master&lt;br/&gt;
&lt;a href=&quot;https://github.com/mongodb/mongo/commit/61f3b37996bcdfff022a301a233c0ae3458eeb8f&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;https://github.com/mongodb/mongo/commit/61f3b37996bcdfff022a301a233c0ae3458eeb8f&lt;/a&gt;&lt;/p&gt;</comment>
                            <comment id="194412" author="auto" created="Tue, 20 Nov 2012 04:14:49 +0000"  >&lt;p&gt;Author:&lt;/p&gt;
{u&apos;date&apos;: u&apos;2012-11-20T04:14:31Z&apos;, u&apos;email&apos;: u&apos;aaron@10gen.com&apos;, u&apos;name&apos;: u&apos;Aaron&apos;}
&lt;p&gt;Message: &lt;a href=&quot;https://jira.mongodb.org/browse/SERVER-1752&quot; title=&quot;improve the performance of simple counts&quot; class=&quot;issue-link&quot; data-issue-key=&quot;SERVER-1752&quot;&gt;&lt;del&gt;SERVER-1752&lt;/del&gt;&lt;/a&gt; Fix rhel compile by using set&amp;lt;&amp;gt; instead of unordered_set&amp;lt;&amp;gt;.&lt;br/&gt;
Branch: master&lt;br/&gt;
&lt;a href=&quot;https://github.com/mongodb/mongo/commit/0a25fc37d3ad50cefea7e19f9866f63f5d2ea2e7&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;https://github.com/mongodb/mongo/commit/0a25fc37d3ad50cefea7e19f9866f63f5d2ea2e7&lt;/a&gt;&lt;/p&gt;</comment>
                            <comment id="194373" author="auto" created="Tue, 20 Nov 2012 03:04:51 +0000"  >&lt;p&gt;Author:&lt;/p&gt;
{u&apos;date&apos;: u&apos;2012-11-20T03:03:59Z&apos;, u&apos;email&apos;: u&apos;aaron@10gen.com&apos;, u&apos;name&apos;: u&apos;Aaron&apos;}
&lt;p&gt;Message: &lt;a href=&quot;https://jira.mongodb.org/browse/SERVER-1752&quot; title=&quot;improve the performance of simple counts&quot; class=&quot;issue-link&quot; data-issue-key=&quot;SERVER-1752&quot;&gt;&lt;del&gt;SERVER-1752&lt;/del&gt;&lt;/a&gt; Fix linux compile by including namespace_details-inl.h.&lt;br/&gt;
Branch: master&lt;br/&gt;
&lt;a href=&quot;https://github.com/mongodb/mongo/commit/b8b020232b893c55056fdacffd51a13dc3546725&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;https://github.com/mongodb/mongo/commit/b8b020232b893c55056fdacffd51a13dc3546725&lt;/a&gt;&lt;/p&gt;</comment>
                            <comment id="194361" author="auto" created="Tue, 20 Nov 2012 02:45:08 +0000"  >&lt;p&gt;Author:&lt;/p&gt;
{u&apos;date&apos;: u&apos;2012-11-04T21:55:36Z&apos;, u&apos;email&apos;: u&apos;aaron@10gen.com&apos;, u&apos;name&apos;: u&apos;Aaron&apos;}
&lt;p&gt;Message: &lt;a href=&quot;https://jira.mongodb.org/browse/SERVER-1752&quot; title=&quot;improve the performance of simple counts&quot; class=&quot;issue-link&quot; data-issue-key=&quot;SERVER-1752&quot;&gt;&lt;del&gt;SERVER-1752&lt;/del&gt;&lt;/a&gt; Optimize simple indexed counts by counting the number of btree keys in a range, without checking the bson value of each key.&lt;br/&gt;
Branch: master&lt;br/&gt;
&lt;a href=&quot;https://github.com/mongodb/mongo/commit/428bb865bfd24848ffba0fb9b9514264e5b3816e&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;https://github.com/mongodb/mongo/commit/428bb865bfd24848ffba0fb9b9514264e5b3816e&lt;/a&gt;&lt;/p&gt;</comment>
                            <comment id="186077" author="auto" created="Mon, 12 Nov 2012 04:27:38 +0000"  >&lt;p&gt;Author:&lt;/p&gt;
{u&apos;date&apos;: u&apos;2012-11-04T21:55:36Z&apos;, u&apos;email&apos;: u&apos;aaron@10gen.com&apos;, u&apos;name&apos;: u&apos;Aaron&apos;}
&lt;p&gt;Message: &lt;a href=&quot;https://jira.mongodb.org/browse/SERVER-1752&quot; title=&quot;improve the performance of simple counts&quot; class=&quot;issue-link&quot; data-issue-key=&quot;SERVER-1752&quot;&gt;&lt;del&gt;SERVER-1752&lt;/del&gt;&lt;/a&gt; Move BtreeCursor class definition to its own header file.&lt;br/&gt;
Branch: master&lt;br/&gt;
&lt;a href=&quot;https://github.com/mongodb/mongo/commit/70361a4125edeeae8427bae122ac361a1c6c2697&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;https://github.com/mongodb/mongo/commit/70361a4125edeeae8427bae122ac361a1c6c2697&lt;/a&gt;&lt;/p&gt;</comment>
                            <comment id="179931" author="tres" created="Mon, 29 Oct 2012 00:01:13 +0000"  >&lt;p&gt;@Jon is right. There are a few glaring issues, such as &lt;a href=&quot;https://jira.mongodb.org/browse/SERVER-863&quot; title=&quot;Tokenize the field names&quot; class=&quot;issue-link&quot; data-issue-key=&quot;SERVER-863&quot;&gt;&lt;del&gt;SERVER-863&lt;/del&gt;&lt;/a&gt;, that really need to be addressed. Surely these are higher priority than a lof of other issues that get prioritised into releases instead.&lt;/p&gt;</comment>
                            <comment id="178521" author="auto" created="Wed, 24 Oct 2012 03:55:35 +0000"  >&lt;p&gt;Author:&lt;/p&gt;
{u&apos;date&apos;: u&apos;2012-10-23T20:53:57-07:00&apos;, u&apos;email&apos;: u&apos;aaron@10gen.com&apos;, u&apos;name&apos;: u&apos;Aaron&apos;}
&lt;p&gt;Message: &lt;a href=&quot;https://jira.mongodb.org/browse/SERVER-1752&quot; title=&quot;improve the performance of simple counts&quot; class=&quot;issue-link&quot; data-issue-key=&quot;SERVER-1752&quot;&gt;&lt;del&gt;SERVER-1752&lt;/del&gt;&lt;/a&gt; Use boost::shared_ptr in cursortests.cpp for windows compilation.&lt;br/&gt;
Branch: master&lt;br/&gt;
&lt;a href=&quot;https://github.com/mongodb/mongo/commit/591d4580587772e2ac3515bcbe3733bb545205b4&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;https://github.com/mongodb/mongo/commit/591d4580587772e2ac3515bcbe3733bb545205b4&lt;/a&gt;&lt;/p&gt;</comment>
                            <comment id="178474" author="auto" created="Wed, 24 Oct 2012 00:17:21 +0000"  >&lt;p&gt;Author:&lt;/p&gt;
{u&apos;date&apos;: u&apos;2012-10-14T20:48:04-07:00&apos;, u&apos;email&apos;: u&apos;aaron@10gen.com&apos;, u&apos;name&apos;: u&apos;Aaron&apos;}
&lt;p&gt;Message: &lt;a href=&quot;https://jira.mongodb.org/browse/SERVER-1752&quot; title=&quot;improve the performance of simple counts&quot; class=&quot;issue-link&quot; data-issue-key=&quot;SERVER-1752&quot;&gt;&lt;del&gt;SERVER-1752&lt;/del&gt;&lt;/a&gt; &lt;a href=&quot;https://jira.mongodb.org/browse/SERVER-4529&quot; title=&quot;fast count mode should not be used when matching against null&quot; class=&quot;issue-link&quot; data-issue-key=&quot;SERVER-4529&quot;&gt;&lt;del&gt;SERVER-4529&lt;/del&gt;&lt;/a&gt; Do not incorrectly use fast count mode when matching against a null value.&lt;br/&gt;
Branch: master&lt;br/&gt;
&lt;a href=&quot;https://github.com/mongodb/mongo/commit/87204cc9de8578fff716ef1b0bb0b707a0b2d04a&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;https://github.com/mongodb/mongo/commit/87204cc9de8578fff716ef1b0bb0b707a0b2d04a&lt;/a&gt;&lt;/p&gt;</comment>
                            <comment id="178473" author="auto" created="Wed, 24 Oct 2012 00:17:19 +0000"  >&lt;p&gt;Author:&lt;/p&gt;
{u&apos;date&apos;: u&apos;2012-10-11T11:44:38-07:00&apos;, u&apos;email&apos;: u&apos;aaron@10gen.com&apos;, u&apos;name&apos;: u&apos;Aaron&apos;}
&lt;p&gt;Message: &lt;a href=&quot;https://jira.mongodb.org/browse/SERVER-1752&quot; title=&quot;improve the performance of simple counts&quot; class=&quot;issue-link&quot; data-issue-key=&quot;SERVER-1752&quot;&gt;&lt;del&gt;SERVER-1752&lt;/del&gt;&lt;/a&gt; Improve performance of simple counts by avoiding use of a matcher when an optimal btree cursor can filter results internally.&lt;br/&gt;
Branch: master&lt;br/&gt;
&lt;a href=&quot;https://github.com/mongodb/mongo/commit/c0355ccbf0a3e242fe2db1427989bcd22311ac4c&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;https://github.com/mongodb/mongo/commit/c0355ccbf0a3e242fe2db1427989bcd22311ac4c&lt;/a&gt;&lt;/p&gt;</comment>
                            <comment id="178472" author="auto" created="Wed, 24 Oct 2012 00:17:17 +0000"  >&lt;p&gt;Author:&lt;/p&gt;
{u&apos;date&apos;: u&apos;2012-10-10T13:33:07-07:00&apos;, u&apos;email&apos;: u&apos;aaron@10gen.com&apos;, u&apos;name&apos;: u&apos;Aaron&apos;}
&lt;p&gt;Message: &lt;a href=&quot;https://jira.mongodb.org/browse/SERVER-1752&quot; title=&quot;improve the performance of simple counts&quot; class=&quot;issue-link&quot; data-issue-key=&quot;SERVER-1752&quot;&gt;&lt;del&gt;SERVER-1752&lt;/del&gt;&lt;/a&gt; Within BtreeCursor::currentMatches(), filter keys that do not match the FieldRangeVector&apos;s index bounds.&lt;br/&gt;
Branch: master&lt;br/&gt;
&lt;a href=&quot;https://github.com/mongodb/mongo/commit/40020f6e56381b1fc6533aa3e85cf01f568ccaea&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;https://github.com/mongodb/mongo/commit/40020f6e56381b1fc6533aa3e85cf01f568ccaea&lt;/a&gt;&lt;/p&gt;</comment>
                            <comment id="173454" author="auto" created="Wed, 10 Oct 2012 18:30:24 +0000"  >&lt;p&gt;Author:&lt;/p&gt;
{u&apos;date&apos;: u&apos;2012-10-09T09:38:18-07:00&apos;, u&apos;email&apos;: u&apos;aaron@10gen.com&apos;, u&apos;name&apos;: u&apos;Aaron&apos;}
&lt;p&gt;Message: &lt;a href=&quot;https://jira.mongodb.org/browse/SERVER-1752&quot; title=&quot;improve the performance of simple counts&quot; class=&quot;issue-link&quot; data-issue-key=&quot;SERVER-1752&quot;&gt;&lt;del&gt;SERVER-1752&lt;/del&gt;&lt;/a&gt; Remove unused Cursor::matcherPtr() function.&lt;br/&gt;
Branch: master&lt;br/&gt;
&lt;a href=&quot;https://github.com/mongodb/mongo/commit/25985c2e2c3e4c02c4c24b9b401bb6d67930028f&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;https://github.com/mongodb/mongo/commit/25985c2e2c3e4c02c4c24b9b401bb6d67930028f&lt;/a&gt;&lt;/p&gt;</comment>
                            <comment id="163604" author="jonhyman" created="Wed, 12 Sep 2012 19:10:55 +0000"  >&lt;p&gt;The 10gen team already knows what to do; it should just be fixed. Documenting it creates an excuse for accepting bad performance.&lt;/p&gt;</comment>
                            <comment id="163564" author="treeder" created="Wed, 12 Sep 2012 18:27:03 +0000"  >&lt;p&gt;@Chad: We started using counters everywhere. Although they create more write locks since you have to update the counters all the time, the queries on the counters are super fast which is much better than indeterminately long count() queries. Another thing we&apos;ve done specifically for pagination is we don&apos;t show the total number of items/pages when paging, instead we do it more Google like where we show a few numbers they can click and a Next link. That&apos;s the easiest way to avoid doing a count() for paging without needing counters.&lt;/p&gt;</comment>
                            <comment id="163563" author="sallgeud" created="Wed, 12 Sep 2012 18:16:33 +0000"  >&lt;p&gt;Travis... What about using it to determine paging requirements for a dynamic grid display?  I think that&apos;s very likely the case that most people are seeing.  Paging of large chunks of data is fairly important, and often times that means you need to know how much data you&apos;ll be paging.&lt;/p&gt;</comment>
                            <comment id="163551" author="treeder" created="Wed, 12 Sep 2012 17:54:14 +0000"  >&lt;p&gt;+1 on documenting this. Nobody should really be using count() except for maybe one off ad-hoc queries, but not in an application where it will be used regularly. &lt;/p&gt;</comment>
                            <comment id="163489" author="michael" created="Wed, 12 Sep 2012 15:44:13 +0000"  >&lt;p&gt;Just got bit by this one as well.  Naive pagination in our application was growing linearly with the collection size.  If optimizing this in a reasonable amount of time is not an option, then I would strongly encourage 10gen to make this &lt;b&gt;very clear&lt;/b&gt; in the documentation.&lt;/p&gt;</comment>
                            <comment id="157838" author="crudson" created="Wed, 29 Aug 2012 05:54:58 +0000"  >&lt;p&gt;This is a biggie.&lt;/p&gt;

&lt;p&gt;We have to do a very large number of counts for some analyses, and even with an index on the attribute (I run with --notablescan, so it has to be there), setting limit to 2, and count(true) it can take a very long time just to determine if more than one document matches a find()(&amp;gt;1 second for ~2million records). This is with ruby.&lt;/p&gt;

&lt;p&gt;I think I am better calling .next() twice on the cursor to determine whether count==1 and do away with count altogether for the time being.&lt;/p&gt;</comment>
                            <comment id="153325" author="bellowsj" created="Tue, 14 Aug 2012 17:58:24 +0000"  >&lt;p&gt;We are also having major problems with count() being too slow. Would love to see this optimized ASAP. &lt;/p&gt;</comment>
                            <comment id="150051" author="treeder" created="Thu, 2 Aug 2012 20:46:29 +0000"  >&lt;p&gt;We&apos;ve run into this countless (no pun intended) times and like the issue says, count() is pretty much unusable. &lt;/p&gt;

&lt;p&gt;Here is an example of how bad and inconsistent it is. Under no load, it&apos;s generally very fast, like a couple of ms, but when we apply a bit of load, the time it takes to execute can be anywhere from a few ms to to 28 minutes!!&lt;/p&gt;

&lt;p&gt;Aug 02 00:29:40 23.23.16.13 kernel:  staging: 2012/08/02 07:29:40 reserved count time 1 ms&lt;br/&gt;
Aug 02 00:29:40 23.20.59.35 kernel:  staging: 2012/08/02 07:29:40 reserved count time 18 ms&lt;br/&gt;
Aug 02 00:29:40 23.22.42.204 kernel:  staging: 2012/08/02 07:29:40 reserved count time 1 ms&lt;br/&gt;
Aug 02 00:29:41 23.23.16.13 kernel:  staging: 2012/08/02 07:29:40 reserved count time 20 ms&lt;br/&gt;
Aug 02 00:29:41 23.22.141.160 kernel:  staging: 2012/08/02 07:29:41 reserved count time 1 ms&lt;br/&gt;
Aug 02 00:30:40 23.22.141.160 kernel:  staging: 2012/08/02 07:30:40 reserved count time 11 ms&lt;br/&gt;
Aug 02 00:30:41 23.23.16.13 kernel:  staging: 2012/08/02 07:30:41 reserved count time 15 ms&lt;br/&gt;
Aug 02 00:31:34 23.23.16.13 kernel:  staging: 2012/08/02 07:31:34 reserved count time 1 ms&lt;br/&gt;
Aug 02 00:31:34 23.23.16.13 kernel:  staging: 2012/08/02 07:31:34 reserved count time 1 ms&lt;br/&gt;
Aug 02 00:31:34 50.17.58.70 kernel:  staging: 2012/08/02 07:31:34 reserved count time 1 ms&lt;br/&gt;
Aug 02 00:31:34 23.20.59.35 kernel:  staging: 2012/08/02 07:31:34 reserved count time 10 ms&lt;br/&gt;
Aug 02 00:31:34 23.23.16.13 kernel:  staging: 2012/08/02 07:31:34 reserved count time 15 ms&lt;br/&gt;
Aug 02 00:31:34 23.20.59.35 kernel:  staging: 2012/08/02 07:31:34 reserved count time 14 ms&lt;br/&gt;
Aug 02 00:31:34 23.20.59.35 kernel:  staging: 2012/08/02 07:31:34 reserved count time 24 ms&lt;br/&gt;
Aug 02 00:31:34 23.22.141.160 kernel:  staging: 2012/08/02 07:31:34 reserved count time 12 ms&lt;br/&gt;
Aug 02 00:31:34 23.22.42.204 kernel:  staging: 2012/08/02 07:31:34 reserved count time 8 ms&lt;br/&gt;
Aug 02 00:33:33 23.20.59.35 kernel:  staging: 2012/08/02 07:33:33 reserved count time 1 ms&lt;br/&gt;
Aug 02 00:34:07 23.23.16.13 kernel:  staging: 2012/08/02 07:34:07 reserved count time 1 ms&lt;br/&gt;
Aug 02 00:36:07 23.23.16.13 kernel:  staging: 2012/08/02 07:36:07 reserved count time 1 ms&lt;br/&gt;
Aug 02 00:37:10 50.17.58.70 kernel:  staging: 2012/08/02 07:37:10 reserved count time 3227 ms&lt;br/&gt;
Aug 02 00:37:10 23.23.16.13 kernel:  staging: 2012/08/02 07:37:10 reserved count time 1 ms&lt;br/&gt;
Aug 02 00:37:10 23.22.42.204 kernel:  staging: 2012/08/02 07:37:10 reserved count time 1 ms&lt;br/&gt;
Aug 02 00:37:11 23.22.42.204 kernel:  staging: 2012/08/02 07:37:11 reserved count time 1417 ms&lt;br/&gt;
Aug 02 00:37:12 50.17.58.70 kernel:  staging: 2012/08/02 07:37:12 reserved count time 64286 ms&lt;br/&gt;
Aug 02 00:37:12 23.20.59.35 kernel:  staging: 2012/08/02 07:37:12 reserved count time 125554 ms&lt;br/&gt;
Aug 02 00:37:13 23.23.16.13 kernel:  staging: 2012/08/02 07:37:13 reserved count time 160238 ms&lt;br/&gt;
Aug 02 00:37:13 23.22.42.204 kernel:  staging: 2012/08/02 07:37:13 reserved count time 1715 ms&lt;br/&gt;
Aug 02 00:37:13 23.23.16.13 kernel:  staging: 2012/08/02 07:37:13 reserved count time 3 ms&lt;br/&gt;
Aug 02 00:37:13 23.22.141.160 kernel:  staging: 2012/08/02 07:37:13 reserved count time 185928 ms&lt;br/&gt;
Aug 02 00:37:14 23.22.42.204 kernel:  staging: 2012/08/02 07:37:14 reserved count time 707 ms&lt;br/&gt;
Aug 02 00:37:14 50.17.58.70 kernel:  staging: 2012/08/02 07:37:14 reserved count time 3 ms&lt;br/&gt;
Aug 02 00:37:14 23.22.42.204 kernel:  staging: 2012/08/02 07:37:14 reserved count time 2 ms&lt;br/&gt;
Aug 02 00:37:14 23.23.16.13 kernel:  staging: 2012/08/02 07:37:14 reserved count time 833 ms&lt;br/&gt;
Aug 02 00:37:14 23.22.141.160 kernel:  staging: 2012/08/02 07:37:14 reserved count time 2 ms&lt;br/&gt;
Aug 02 00:37:14 23.20.59.35 kernel:  staging: 2012/08/02 07:37:14 reserved count time 1 ms&lt;br/&gt;
Aug 02 00:37:14 23.22.141.160 kernel:  staging: 2012/08/02 07:37:14 reserved count time 707687 ms&lt;br/&gt;
Aug 02 00:37:15 23.23.16.13 kernel:  staging: 2012/08/02 07:37:15 reserved count time 767091 ms&lt;br/&gt;
Aug 02 00:37:15 23.22.141.160 kernel:  staging: 2012/08/02 07:37:15 reserved count time 221417 ms&lt;br/&gt;
Aug 02 00:37:15 50.17.58.70 kernel:  staging: 2012/08/02 07:37:15 reserved count time 1010 ms&lt;br/&gt;
Aug 02 00:37:15 50.17.58.70 kernel:  staging: 2012/08/02 07:37:15 reserved count time 866 ms&lt;br/&gt;
Aug 02 00:37:15 23.20.59.35 kernel:  staging: 2012/08/02 07:37:15 reserved count time 755420 ms&lt;br/&gt;
Aug 02 00:37:16 23.23.16.13 kernel:  staging: 2012/08/02 07:37:16 reserved count time 930 ms&lt;br/&gt;
Aug 02 00:37:16 50.17.58.70 kernel:  staging: 2012/08/02 07:37:16 reserved count time 1176 ms&lt;br/&gt;
Aug 02 00:37:16 50.17.58.70 kernel:  staging: 2012/08/02 07:37:16 reserved count time 815492 ms&lt;br/&gt;
Aug 02 00:37:16 23.23.16.13 kernel:  staging: 2012/08/02 07:37:16 reserved count time 450 ms&lt;br/&gt;
Aug 02 00:37:17 23.22.141.160 kernel:  staging: 2012/08/02 07:37:17 reserved count time 697 ms&lt;br/&gt;
Aug 02 00:37:17 23.20.59.35 kernel:  staging: 2012/08/02 07:37:17 reserved count time 7 ms&lt;br/&gt;
Aug 02 00:37:17 50.17.58.70 kernel:  staging: 2012/08/02 07:37:17 reserved count time 2 ms&lt;br/&gt;
Aug 02 00:37:17 23.20.59.35 kernel:  staging: 2012/08/02 07:37:17 reserved count time 627 ms&lt;br/&gt;
Aug 02 00:37:18 50.17.58.70 kernel:  staging: 2012/08/02 07:37:18 reserved count time 641 ms&lt;br/&gt;
Aug 02 00:37:18 23.22.141.160 kernel:  staging: 2012/08/02 07:37:18 reserved count time 741 ms&lt;br/&gt;
Aug 02 00:37:18 23.23.16.13 kernel:  staging: 2012/08/02 07:37:18 reserved count time 2 ms&lt;br/&gt;
Aug 02 00:37:18 23.23.16.13 kernel:  staging: 2012/08/02 07:37:18 reserved count time 2 ms&lt;br/&gt;
Aug 02 00:37:18 23.20.59.35 kernel:  staging: 2012/08/02 07:37:18 reserved count time 458 ms&lt;br/&gt;
Aug 02 00:37:18 50.17.58.70 kernel:  staging: 2012/08/02 07:37:18 reserved count time 632 ms&lt;br/&gt;
Aug 02 00:37:18 23.22.42.204 kernel:  staging: 2012/08/02 07:37:18 reserved count time 62 ms&lt;br/&gt;
Aug 02 00:37:18 23.20.59.35 kernel:  staging: 2012/08/02 07:37:18 reserved count time 6 ms&lt;br/&gt;
Aug 02 00:37:19 23.23.16.13 kernel:  staging: 2012/08/02 07:37:18 reserved count time 7 ms&lt;br/&gt;
Aug 02 00:37:19 23.20.59.35 kernel:  staging: 2012/08/02 07:37:19 reserved count time 631 ms&lt;br/&gt;
Aug 02 00:37:19 23.20.59.35 kernel:  staging: 2012/08/02 07:37:19 reserved count time 611 ms&lt;br/&gt;
Aug 02 00:37:20 23.20.59.35 kernel:  staging: 2012/08/02 07:37:20 reserved count time 472 ms&lt;br/&gt;
Aug 02 00:37:20 23.22.141.160 kernel:  staging: 2012/08/02 07:37:20 reserved count time 2 ms&lt;br/&gt;
Aug 02 00:37:20 23.20.59.35 kernel:  staging: 2012/08/02 07:37:20 reserved count time 5 ms&lt;br/&gt;
Aug 02 00:37:20 50.17.58.70 kernel:  staging: 2012/08/02 07:37:20 reserved count time 398 ms&lt;br/&gt;
Aug 02 00:37:20 23.23.16.13 kernel:  staging: 2012/08/02 07:37:20 reserved count time 6 ms&lt;br/&gt;
Aug 02 00:37:20 23.20.59.35 kernel:  staging: 2012/08/02 07:37:20 reserved count time 3 ms&lt;br/&gt;
Aug 02 00:37:20 23.20.59.35 kernel:  staging: 2012/08/02 07:37:20 reserved count time 7 ms&lt;br/&gt;
Aug 02 00:37:22 50.17.58.70 kernel:  staging: 2012/08/02 07:37:22 reserved count time 1325969 ms&lt;br/&gt;
Aug 02 00:37:22 23.22.141.160 kernel:  staging: 2012/08/02 07:37:22 reserved count time 1462886 ms&lt;br/&gt;
Aug 02 00:37:23 50.17.58.70 kernel:  staging: 2012/08/02 07:37:22 reserved count time 1386688 ms&lt;br/&gt;
Aug 02 00:37:26 23.22.42.204 kernel:  staging: 2012/08/02 07:37:26 reserved count time 1407095 ms&lt;br/&gt;
Aug 02 00:37:26 23.23.16.13 kernel:  staging: 2012/08/02 07:37:26 reserved count time 1541300 ms&lt;br/&gt;
Aug 02 00:37:26 50.17.58.70 kernel:  staging: 2012/08/02 07:37:26 reserved count time 1600832 ms&lt;br/&gt;
Aug 02 00:37:27 23.20.59.35 kernel:  staging: 2012/08/02 07:37:27 reserved count time 1623156 ms&lt;br/&gt;
Aug 02 00:37:28 23.22.141.160 kernel:  staging: 2012/08/02 07:37:28 reserved count time 1683357 ms&lt;br/&gt;
Aug 02 00:42:44 50.17.58.70 kernel:  staging: 2012/08/02 07:42:44 reserved count time 1 ms&lt;br/&gt;
Aug 02 00:43:26 23.22.141.160 kernel:  staging: 2012/08/02 07:43:26 reserved count time 42227 ms&lt;br/&gt;
Aug 02 00:43:26 23.22.42.204 kernel:  staging: 2012/08/02 07:43:26 reserved count time 1 ms&lt;br/&gt;
Aug 02 00:43:26 23.20.59.35 kernel:  staging: 2012/08/02 07:43:26 reserved count time 1 ms&lt;br/&gt;
Aug 02 00:43:27 23.22.42.204 kernel:  staging: 2012/08/02 07:43:27 reserved count time 432 ms&lt;/p&gt;</comment>
                            <comment id="147666" author="jonhyman" created="Thu, 26 Jul 2012 17:13:10 +0000"  >&lt;p&gt;Please commit to doing this in 2.3.0. We&apos;re having to start looking at rewriting parts of our code to not use MongoDB due to slow count performance.&lt;/p&gt;</comment>
                            <comment id="147595" author="davefooks" created="Thu, 26 Jul 2012 15:11:48 +0000"  >&lt;p&gt;Ah, ok sounds like it should make a big difference! Thanks for the update.&lt;/p&gt;</comment>
                            <comment id="147593" author="eliot" created="Thu, 26 Jul 2012 15:06:08 +0000"  >&lt;p&gt;Main issue is that we do actually do the key comparison for every doc.&lt;br/&gt;
So if you just find the min and max sections of the btree for a key, and do a simple count of the entries, it&apos;ll be close to an order of magnitude faster.&lt;/p&gt;</comment>
                            <comment id="147589" author="davefooks" created="Thu, 26 Jul 2012 15:03:04 +0000"  >&lt;p&gt;@Eliot Out of interest how are you optimizing this? What sort of speed up do you expect to gain from it?&lt;/p&gt;

&lt;p&gt;To be honest I&apos;m more interested in how this might affect &lt;a href=&quot;https://jira.mongodb.org/browse/SERVER-2274&quot; class=&quot;external-link&quot; rel=&quot;nofollow&quot;&gt;https://jira.mongodb.org/browse/SERVER-2274&lt;/a&gt; as I&apos;ve been holding off writing a work around until our collection gets too big and these count operations become too slow.&lt;/p&gt;</comment>
                            <comment id="147566" author="eliot" created="Thu, 26 Jul 2012 14:34:42 +0000"  >&lt;p&gt;@david - no, counting b-trees are generally not something we think make sense, this is is more of straight optimization, but could be significant. &lt;/p&gt;</comment>
                            <comment id="147517" author="solars" created="Thu, 26 Jul 2012 11:46:00 +0000"  >&lt;p&gt;Apologies, I meant basic from the user perspective. Our pagination does the count which seems trivial from that perspective, but slows down the whole application ..&lt;/p&gt;

&lt;p&gt;I can of course not judge if it is basic from an implementation point of view&lt;/p&gt;</comment>
                            <comment id="147504" author="davefooks" created="Thu, 26 Jul 2012 10:50:47 +0000"  >&lt;p&gt;@Christoph I&apos;m not sure this is a basic problem. I think they will need to implement counted b-trees as a whole new type of index.&lt;br/&gt;
@Eliot Is this correct? if so won&apos;t this also fix &lt;a href=&quot;https://jira.mongodb.org/browse/SERVER-2274?&quot; class=&quot;external-link&quot; rel=&quot;nofollow&quot;&gt;https://jira.mongodb.org/browse/SERVER-2274?&lt;/a&gt;&lt;/p&gt;
</comment>
                            <comment id="147498" author="solars" created="Thu, 26 Jul 2012 10:16:00 +0000"  >&lt;p&gt;we also have this very basic problem - quite annoying, I hope there is a fix soon&lt;/p&gt;</comment>
                            <comment id="145885" author="eliot" created="Sun, 22 Jul 2012 12:51:55 +0000"  >&lt;p&gt;20 seconds for 50k still doesn&apos;t make sense, so if you could send the explain would be interesting&lt;/p&gt;</comment>
                            <comment id="145704" author="jamesharrison" created="Sat, 21 Jul 2012 15:03:32 +0000"  >&lt;p&gt;@Eliot - The &apos;fix version&apos; has changed on this ticket at least once. &lt;/p&gt;

&lt;p&gt;If this /is/ getting fixed for 2.3, that&apos;s great. If it&apos;s just &apos;that&apos;s the one we&apos;re not doing now&apos; as it kinda looks, then it&apos;ll be time to look for another solution.&lt;/p&gt;

&lt;p&gt;The server is doing 100 reqs/s on average, with about 50 reqs/s being counts. This server is thrashing itself resolving these queries. Since the queries are user-specific, caching in appspace yields limited results, though we&apos;re looking at doing some more of that. As far as explain goes - the same query being used for a count run as a &lt;del&gt;find&lt;/del&gt; is yielding within a millisecond and for those queries we&apos;re very happy with MongoDB.&lt;/p&gt;</comment>
                            <comment id="145689" author="eliot" created="Sat, 21 Jul 2012 12:48:37 +0000"  >&lt;p&gt;@James - if 50k entries takes 20 seconds, I don&apos;t think that has anything to with this issue.  Sounds like something else.&lt;br/&gt;
Can you post a new ticket with the explain?&lt;/p&gt;

&lt;p&gt;This is scheduled for 2.3.0, which is the next dev cycle, see &quot;fix version&quot; above.&lt;/p&gt;</comment>
                            <comment id="145688" author="scoulibaly" created="Sat, 21 Jul 2012 12:46:12 +0000"  >&lt;p&gt;@James Harrison :&lt;br/&gt;
I guess the answer from MongoDb will be &quot;Why don&apos;t you shard and map reduce your 50 000 entries over 50 additionnal machines ?&quot;, or &quot;Retrieve the whole collection on client side and count the item...&quot;.&lt;/p&gt;

&lt;p&gt;This issue is just frustrating and really worrying as you said.&lt;/p&gt;

&lt;p&gt;Seen absolutely no progress on this since I started with MongoDb (never commited to Mongo, since this bug was never corrected) with 1.8...&lt;/p&gt;

&lt;p&gt;An update on &quot;why this ins not fixed, why a fix is not planned&quot; from 10gen would be great.&lt;/p&gt;</comment>
                            <comment id="145687" author="jamesharrison" created="Sat, 21 Jul 2012 12:34:28 +0000"  >&lt;p&gt;Given the large number of use cases which depend on quick count() performance (pagination being one of the more obvious generally applicable cases), is this ever going to get looked at? The fact that it has been sat at high priority for so long raises some worrying questions. For collections of 50,000 entries on a very fast machine (8 cores, 16GB RAM, Intel SSDs) we&apos;ve seen counts that take in excess of 20 seconds per call. Given 50,000 entries is not by any stretch a particularly large collection and that we&apos;re growing that collection by about 1.5k a day, we&apos;re now having to consider rewriting large chunks of code and removing functionality to avoid this bug, or moving from MongoDB.&lt;/p&gt;</comment>
                            <comment id="109968" author="adrien" created="Sun, 15 Apr 2012 10:10:17 +0000"  >&lt;p&gt;Browsing and counting 500 elements is pretty fast, you shouldn&apos;t be affected. If you&apos;re using your whole set, you may also retrieve it entirely and count elements in your client code.&lt;/p&gt;</comment>
                            <comment id="109964" author="ssharma@saba.com" created="Sun, 15 Apr 2012 09:48:37 +0000"  >&lt;p&gt;This will affect us in production since for paging we need the count of total records. &lt;/p&gt;

&lt;p&gt;Will the same affect us if total count of results for a query is &amp;lt; 500 records?&lt;/p&gt;

&lt;p&gt;-Sid&lt;/p&gt;</comment>
                            <comment id="90703" author="kevin@indeed.com" created="Wed, 22 Feb 2012 02:15:11 +0000"  >&lt;p&gt;Is there a way to quickly check how many records are in an index? (like the quick count for number of objects in a collection)&lt;/p&gt;

&lt;p&gt;Actually running the count({}) is brutally slow and creates a lot of disk I/O if the index you want to check isn&apos;t already cached.&lt;/p&gt;</comment>
                            <comment id="36182" author="adrien" created="Sun, 5 Jun 2011 10:34:11 +0000"  >&lt;p&gt;Getting an estimated result in a very short time could be acceptable in some cases.&lt;br/&gt;
For instance I need to get total results to display a paginated list, but it does not require the exact number.&lt;/p&gt;

&lt;p&gt;Getting the depth of the (indexed criteria) subtree, with its average width could be a first optimization effort ? It&apos;s a kind of mysql trick in innoDB indexes if I remember...&lt;/p&gt;</comment>
                            <comment id="35268" author="remonvv" created="Tue, 31 May 2011 11:38:56 +0000"  >&lt;p&gt;Duplicate of 2274.&lt;/p&gt;

&lt;p&gt;An actual scan should not be necessary for &quot;attr&quot; that have primary types and are covered by an index, assuming it is a counted btree. If not adding subtree node counts should speed this up significantly. Given the common use of range based count() operations as well as it&apos;s direct relation to result paging and such I do agree that it would be very nice to get this into one of the early 2.x versions if at all possible.&lt;/p&gt;</comment>
                            <comment id="32230" author="lennartkoopmann" created="Thu, 12 May 2011 08:46:53 +0000"  >&lt;p&gt;+1&lt;/p&gt;

&lt;p&gt;What is the status on this? We need to work around this stuff in Graylog2 because it is too slow.&lt;/p&gt;</comment>
                            <comment id="30679" author="scoulibaly" created="Mon, 2 May 2011 19:47:17 +0000"  >&lt;p&gt;Running 1.8.1 here, same issue.&lt;/p&gt;

&lt;p&gt;Roughly 10 seconds to count around 10 millions documents based on attr:val (99% of the documents have same integer value for attr) on an 8 proc box, 16GB RAM, and a 4GB mongo base.&lt;br/&gt;
No i/o activity during the query, the whole base seems in RAM already.&lt;/p&gt;

&lt;p&gt;AG:&lt;br/&gt;
&quot;we are indeed planning to improve the perf of count(), right now the&lt;br/&gt;
reason it is slow is that the comparison between value is sub optimal,&lt;br/&gt;
even on simple integers.&quot;&lt;/p&gt;

&lt;p&gt;A little disappointing for such a basic need, would be nice if this was scheduled, better if before December 2012 !&lt;/p&gt;


</comment>
                            <comment id="29495" author="eliot" created="Fri, 22 Apr 2011 07:30:35 +0000"  >&lt;p&gt;Scanning 3 M records is going to take some time, even with an index.&lt;br/&gt;
If you want to make sure your case is handled as well as possible currently, please follow up on &lt;a href=&quot;http://groups.google.com/group/mongodb-user/&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;http://groups.google.com/group/mongodb-user/&lt;/a&gt;&lt;/p&gt;</comment>
                            <comment id="29376" author="dougtmayer" created="Wed, 20 Apr 2011 16:04:35 +0000"  >&lt;p&gt;Can this really go on as unscheduled for this long? We&apos;re experiencing very long wait times on this type of query with only 3 million records. It seems like it would be a very common operation, which makes me feel like we must be doing something wrong?&lt;/p&gt;

&lt;p&gt;Can someone on the core server team at least confirm this isn&apos;t a misuse or misconfiguration on our part to try to get the ball rolling on it?&lt;/p&gt;</comment>
                            <comment id="22811" author="adrien" created="Sat, 29 Jan 2011 22:38:14 +0000"  >&lt;p&gt;You can vote for &lt;a href=&quot;http://jira.mongodb.org/browse/SERVER-2435&quot; class=&quot;external-link&quot; rel=&quot;nofollow&quot;&gt;http://jira.mongodb.org/browse/SERVER-2435&lt;/a&gt;&lt;/p&gt;</comment>
                            <comment id="22303" author="adrien" created="Wed, 12 Jan 2011 21:13:34 +0000"  >&lt;p&gt;I experience similar issue in my 3 shards configurations. When I attempt to perform a count() an a field (not the shard-key, but indexed anyway) it can take more than 30s. (1 million matching results to count within 200 000 millions rows).&lt;/p&gt;</comment>
                            <comment id="22297" author="klu2" created="Wed, 12 Jan 2011 19:51:20 +0000"  >&lt;p&gt;You might also vote for &lt;a href=&quot;http://jira.mongodb.org/browse/SERVER-2274&quot; class=&quot;external-link&quot; rel=&quot;nofollow&quot;&gt;http://jira.mongodb.org/browse/SERVER-2274&lt;/a&gt;&lt;/p&gt;</comment>
                            <comment id="22296" author="klu2" created="Wed, 12 Jan 2011 19:48:01 +0000"  >&lt;p&gt;We experience similar issues and as that came to be quite a show-stopper for our app, we introduced a cache in our Java Applicaiton Server that caches the count result for queries and then returns that number for a couple of time. Depending on how your queries look like, that might be quite hard to implement.&lt;/p&gt;</comment>
                    </comments>
                <issuelinks>
                            <issuelinktype id="10011">
                    <name>Depends</name>
                                                                <inwardlinks description="is depended on by">
                                                        </inwardlinks>
                                    </issuelinktype>
                            <issuelinktype id="10010">
                    <name>Duplicate</name>
                                                                <inwardlinks description="is duplicated by">
                                        <issuelink>
            <issuekey id="14058">SERVER-2274</issuekey>
        </issuelink>
                            </inwardlinks>
                                    </issuelinktype>
                            <issuelinktype id="10012">
                    <name>Related</name>
                                            <outwardlinks description="related to">
                                        <issuelink>
            <issuekey id="14354">SERVER-2435</issuekey>
        </issuelink>
            <issuelink>
            <issuekey id="28648">SERVER-4717</issuekey>
        </issuelink>
                            </outwardlinks>
                                                                <inwardlinks description="is related to">
                                        <issuelink>
            <issuekey id="57213">SERVER-7745</issuekey>
        </issuelink>
            <issuelink>
            <issuekey id="60102">SERVER-8004</issuekey>
        </issuelink>
                            </inwardlinks>
                                    </issuelinktype>
                    </issuelinks>
                <attachments>
                    </attachments>
                <subtasks>
                    </subtasks>
                <customfields>
                                                <customfield id="customfield_10050" key="com.atlassian.jira.toolkit:comments">
                        <customfieldname># Replies</customfieldname>
                        <customfieldvalues>
                            <customfieldvalue>50.0</customfieldvalue>
                        </customfieldvalues>
                    </customfield>
                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                <customfield id="customfield_10055" key="com.atlassian.jira.ext.charting:firstresponsedate">
                        <customfieldname>Date of 1st Reply</customfieldname>
                        <customfieldvalues>
                            <customfieldvalue>Wed, 12 Jan 2011 19:48:01 +0000</customfieldvalue>

                        </customfieldvalues>
                    </customfield>
                                                                <customfield id="customfield_10052" key="com.atlassian.jira.toolkit:dayslastcommented">
                        <customfieldname>Days since reply</customfieldname>
                        <customfieldvalues>
                                        11 years, 8 weeks, 5 days ago
    
                        </customfieldvalues>
                    </customfield>
                                                                <customfield id="customfield_18254" key="com.onresolve.jira.groovy.groovyrunner:scripted-field">
                        <customfieldname>Dependencies</customfieldname>
                        <customfieldvalues>
                            <customfieldvalue><![CDATA[]]></customfieldvalue>


                        </customfieldvalues>
                    </customfield>
                                                                <customfield id="customfield_15850" key="com.atlassian.jira.plugins.jira-development-integration-plugin:devsummary">
                        <customfieldname>Development</customfieldname>
                        <customfieldvalues>
                            
                        </customfieldvalues>
                    </customfield>
                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                        <customfield id="customfield_10057" key="com.atlassian.jira.toolkit:lastusercommented">
                        <customfieldname>Last comment by Customer</customfieldname>
                        <customfieldvalues>
                            <customfieldvalue>true</customfieldvalue>
                        </customfieldvalues>
                    </customfield>
                                                                                            <customfield id="customfield_10056" key="com.atlassian.jira.toolkit:lastupdaterorcommenter">
                        <customfieldname>Last commenter</customfieldname>
                        <customfieldvalues>
                            <customfieldvalue>dan@mongodb.com</customfieldvalue>

                        </customfieldvalues>
                    </customfield>
                                                                <customfield id="customfield_11151" key="com.atlassian.jira.toolkit:LastCommentDate">
                        <customfieldname>Last public comment date</customfieldname>
                        <customfieldvalues>
                            11 years, 8 weeks, 5 days ago
                        </customfieldvalues>
                    </customfield>
                                                                                                                        <customfield id="customfield_10000" key="com.atlassian.jira.plugin.system.customfieldtypes:radiobuttons">
                        <customfieldname>Old_Backport</customfieldname>
                        <customfieldvalues>
                                <customfieldvalue key="10000"><![CDATA[No]]></customfieldvalue>

                        </customfieldvalues>
                    </customfield>
                                                                                                                                                                                <customfield id="customfield_10051" key="com.atlassian.jira.toolkit:participants">
                        <customfieldname>Participants</customfieldname>
                        <customfieldvalues>
                                        <customfieldvalue>aaron</customfieldvalue>
            <customfieldvalue>adrien</customfieldvalue>
            <customfieldvalue>auto</customfieldvalue>
            <customfieldvalue>sallgeud</customfieldvalue>
            <customfieldvalue>solars</customfieldvalue>
            <customfieldvalue>davefooks</customfieldvalue>
            <customfieldvalue>crudson</customfieldvalue>
            <customfieldvalue>dougtmayer</customfieldvalue>
            <customfieldvalue>eliot</customfieldvalue>
            <customfieldvalue>jamesharrison</customfieldvalue>
            <customfieldvalue>bellowsj</customfieldvalue>
            <customfieldvalue>jonhyman</customfieldvalue>
            <customfieldvalue>kevin@indeed.com</customfieldvalue>
            <customfieldvalue>klu2</customfieldvalue>
            <customfieldvalue>lennartkoopmann</customfieldvalue>
            <customfieldvalue>michael</customfieldvalue>
            <customfieldvalue>phoenix</customfieldvalue>
            <customfieldvalue>remonvv</customfieldvalue>
            <customfieldvalue>scoulibaly</customfieldvalue>
            <customfieldvalue>ssharma@saba.com</customfieldvalue>
            <customfieldvalue>treeder</customfieldvalue>
            <customfieldvalue>tres</customfieldvalue>
    
                        </customfieldvalues>
                    </customfield>
                                                                                                                                                                                                                                        <customfield id="customfield_14254" key="com.pyxis.greenhopper.jira:gh-lexo-rank">
                        <customfieldname>Product Rank</customfieldname>
                        <customfieldvalues>
                            <customfieldvalue>1|hrpfon:</customfieldvalue>

                        </customfieldvalues>
                    </customfield>
                                                                                                                                                                                <customfield id="customfield_12550" key="com.pyxis.greenhopper.jira:gh-lexo-rank">
                        <customfieldname>Rank</customfieldname>
                        <customfieldvalues>
                            <customfieldvalue>2|hrfx1j:</customfieldvalue>

                        </customfieldvalues>
                    </customfield>
                                                                <customfield id="customfield_10558" key="com.pyxis.greenhopper.jira:gh-global-rank">
                        <customfieldname>Rank (Obsolete)</customfieldname>
                        <customfieldvalues>
                            <customfieldvalue>5692</customfieldvalue>
                        </customfieldvalues>
                    </customfield>
                                                                                            <customfield id="customfield_23361" key="com.onresolve.jira.groovy.groovyrunner:scripted-field">
                        <customfieldname>Requested By</customfieldname>
                        <customfieldvalues>
                                

                        </customfieldvalues>
                    </customfield>
                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                <customfield id="customfield_10053" key="com.atlassian.jira.ext.charting:timeinstatus">
                        <customfieldname>Time In Status</customfieldname>
                        <customfieldvalues>
                            
                        </customfieldvalues>
                    </customfield>
                                                                                                                                                                                                                                                                                                                                                                                                                                                                        <customfield id="customfield_22870" key="com.onresolve.jira.groovy.groovyrunner:scripted-field">
                        <customfieldname>Triagers</customfieldname>
                        <customfieldvalues>
                                

                        </customfieldvalues>
                    </customfield>
                                                                                                                                                                                                                                                                                                                                                                                    <customfield id="customfield_14350" key="com.pyxis.greenhopper.jira:gh-lexo-rank">
                        <customfieldname>serverRank</customfieldname>
                        <customfieldvalues>
                            <customfieldvalue>1|hrnvdr:</customfieldvalue>

                        </customfieldvalues>
                    </customfield>
                                    </customfields>
    </item>
</channel>
</rss>