<!-- 
RSS generated by JIRA (9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66) at Thu Feb 08 03:32:42 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-13732] Predicates in top-level implicit AND query not considered when generating index access plan for contained OR</title>
                <link>https://jira.mongodb.org/browse/SERVER-13732</link>
                <project id="10000" key="SERVER">Core Server</project>
                    <description>&lt;div class=&quot;panel&quot; style=&quot;background-color: #EEEEEE;border-color: #ccc;border-width: 1px;&quot;&gt;&lt;div class=&quot;panelHeader&quot; style=&quot;border-bottom-width: 1px;border-bottom-color: #ccc;background-color: #6CB33F;&quot;&gt;&lt;b&gt;Issue Status as of Feb 28, 2017&lt;/b&gt;&lt;/div&gt;&lt;div class=&quot;panelContent&quot; style=&quot;background-color: #EEEEEE;&quot;&gt;
&lt;p&gt;&lt;b&gt;ISSUE SUMMARY&lt;/b&gt;&lt;/p&gt;

&lt;p&gt;A &quot;contained &lt;tt&gt;$or&lt;/tt&gt;&quot; is a query predicate which has an explicit or implicit &lt;tt&gt;$and&lt;/tt&gt; at the top level where one of the clauses of the &lt;tt&gt;$and&lt;/tt&gt; is a &lt;tt&gt;$or&lt;/tt&gt;. For instance, the following two predicates are contained &lt;tt&gt;$or&lt;/tt&gt; queries:&lt;/p&gt;

&lt;p/&gt;
&lt;div id=&quot;syntaxplugin&quot; class=&quot;syntaxplugin&quot; style=&quot;border: 1px dashed #bbb; border-radius: 5px !important; overflow: auto; max-height: 30em;&quot;&gt;
&lt;table cellspacing=&quot;0&quot; cellpadding=&quot;0&quot; border=&quot;0&quot; width=&quot;100%&quot; style=&quot;font-size: 1em; line-height: 1.4em !important; font-weight: normal; font-style: normal; color: black;&quot;&gt;
		&lt;tbody &gt;
				&lt;tr id=&quot;syntaxplugin_code_and_gutter&quot;&gt;
						&lt;td  style=&quot; line-height: 1.4em !important; padding: 0em; vertical-align: top;&quot;&gt;
					&lt;pre style=&quot;font-size: 1em; margin: 0 10px;  margin-top: 10px;   width: auto; padding: 0;&quot;&gt;&lt;span style=&quot;color: black; font-family: &apos;Consolas&apos;, &apos;Bitstream Vera Sans Mono&apos;, &apos;Courier New&apos;, Courier, monospace !important;&quot;&gt;{$and: [{a: 1}, {$or: [{b: 1}, {b: 2}]}, {c: 3}]}&lt;/span&gt;&lt;/pre&gt;
			&lt;/td&gt;
		&lt;/tr&gt;
				&lt;tr id=&quot;syntaxplugin_code_and_gutter&quot;&gt;
						&lt;td  style=&quot; line-height: 1.4em !important; padding: 0em; vertical-align: top;&quot;&gt;
					&lt;pre style=&quot;font-size: 1em; margin: 0 10px;   margin-bottom: 10px;  width: auto; padding: 0;&quot;&gt;&lt;span style=&quot;color: black; font-family: &apos;Consolas&apos;, &apos;Bitstream Vera Sans Mono&apos;, &apos;Courier New&apos;, Courier, monospace !important;&quot;&gt;{a: 1, $or: [{b: 1}, {b: 2}], c: 3}&lt;/span&gt;&lt;/pre&gt;
			&lt;/td&gt;
		&lt;/tr&gt;
			&lt;/tbody&gt;
&lt;/table&gt;
&lt;/div&gt;
&lt;p/&gt;

&lt;p&gt;This issue affects contained &lt;tt&gt;$or&lt;/tt&gt; queries. If the query is answered by indexing the contained &lt;tt&gt;$or&lt;/tt&gt;, versions 2.4.x and earlier of the server could also use the predicates outside the &lt;tt&gt;$or&lt;/tt&gt; to constrain the index bounds. Suppose that a collection has two compound indexes {b: 1, a: 1} and {c: 1, a: 1}. Now consider a query with predicate&lt;/p&gt;

&lt;p/&gt;
&lt;div id=&quot;syntaxplugin&quot; class=&quot;syntaxplugin&quot; style=&quot;border: 1px dashed #bbb; border-radius: 5px !important; overflow: auto; max-height: 30em;&quot;&gt;
&lt;table cellspacing=&quot;0&quot; cellpadding=&quot;0&quot; border=&quot;0&quot; width=&quot;100%&quot; style=&quot;font-size: 1em; line-height: 1.4em !important; font-weight: normal; font-style: normal; color: black;&quot;&gt;
		&lt;tbody &gt;
				&lt;tr id=&quot;syntaxplugin_code_and_gutter&quot;&gt;
						&lt;td  style=&quot; line-height: 1.4em !important; padding: 0em; vertical-align: top;&quot;&gt;
					&lt;pre style=&quot;font-size: 1em; margin: 0 10px;  margin-top: 10px;   margin-bottom: 10px;  width: auto; padding: 0;&quot;&gt;&lt;span style=&quot;color: black; font-family: &apos;Consolas&apos;, &apos;Bitstream Vera Sans Mono&apos;, &apos;Courier New&apos;, Courier, monospace !important;&quot;&gt;{a: {$gte: 3, $lte: 6}, $or: [{b: 1}, {c: 2}]}&lt;/span&gt;&lt;/pre&gt;
			&lt;/td&gt;
		&lt;/tr&gt;
			&lt;/tbody&gt;
&lt;/table&gt;
&lt;/div&gt;
&lt;p/&gt;

&lt;p&gt;In versions 2.4.x and earlier, this query is answered by two index scans:&lt;/p&gt;
&lt;ol&gt;
	&lt;li&gt;First scanning index {b: 1, a: 1} for keys where &lt;tt&gt;b&lt;/tt&gt; is equal to 1 and &lt;tt&gt;a&lt;/tt&gt; is on the interval [3, 6], and then&lt;/li&gt;
	&lt;li&gt;scanning index {c: 1, a: 1} for keys where &lt;tt&gt;c&lt;/tt&gt; is equal to 2 and &lt;tt&gt;a&lt;/tt&gt; is on the interval [3, 6].&lt;/li&gt;
&lt;/ol&gt;


&lt;p&gt;However, on versions of the server affected by this issue, both index scans will have unconstrained bounds on field &lt;tt&gt;a&lt;/tt&gt; and may examine keys where the value of &lt;tt&gt;a&lt;/tt&gt; is outside the interval [3, 6].&lt;/p&gt;

&lt;p&gt;Versions 2.4.x and earlier of the server could also use the predicates outside the &lt;tt&gt;$or&lt;/tt&gt; to provide index bounds for the first field in the index. Consider the same query on a collection with two compound indexes {a: 1, b: 1} and {a: 1, c: 1}. In versions 2.4.x and earlier, this query could be answered by two index scans:&lt;/p&gt;
&lt;ol&gt;
	&lt;li&gt;First scanning index {a: 1, b: 1} for keys where &lt;tt&gt;a&lt;/tt&gt; is on the interval [3, 6] and &lt;tt&gt;b&lt;/tt&gt; is equal to 1, and then&lt;/li&gt;
	&lt;li&gt;scanning index {a: 1, c: 1} for keys where &lt;tt&gt;a&lt;/tt&gt; is on the interval [3, 6] and &lt;tt&gt;c&lt;/tt&gt; is equal to 2.&lt;/li&gt;
&lt;/ol&gt;


&lt;p&gt;On versions of the server affected by this issue, this query will always be answered by a single index scan on either {a: 1, b: 1} or {a: 1, c: 1} for keys where &lt;tt&gt;a&lt;/tt&gt; is on the interval [3, 6].&lt;/p&gt;

&lt;p&gt;&lt;b&gt;USER IMPACT&lt;/b&gt;&lt;/p&gt;

&lt;p&gt;Contained &lt;tt&gt;$or&lt;/tt&gt; queries indexed in the manner described above will have looser bounds than they did on previous versions. Depending on the data in the collection, this could mean that the number of index keys examined in order to answer the query will be much higher, causing bad query performance.&lt;/p&gt;

&lt;p&gt;&lt;b&gt;WORKAROUNDS&lt;/b&gt;&lt;/p&gt;

&lt;p&gt;Applications can work around the issue by rewriting contained &lt;tt&gt;$or&lt;/tt&gt; queries as rooted &lt;tt&gt;$or&lt;/tt&gt; queries. A &quot;rooted &lt;tt&gt;$or&lt;/tt&gt;&quot; is a query predicate consisting of a single &lt;tt&gt;$or&lt;/tt&gt; statement. For example, the following query predicate is a rooted &lt;tt&gt;$or&lt;/tt&gt;:&lt;/p&gt;

&lt;p/&gt;
&lt;div id=&quot;syntaxplugin&quot; class=&quot;syntaxplugin&quot; style=&quot;border: 1px dashed #bbb; border-radius: 5px !important; overflow: auto; max-height: 30em;&quot;&gt;
&lt;table cellspacing=&quot;0&quot; cellpadding=&quot;0&quot; border=&quot;0&quot; width=&quot;100%&quot; style=&quot;font-size: 1em; line-height: 1.4em !important; font-weight: normal; font-style: normal; color: black;&quot;&gt;
		&lt;tbody &gt;
				&lt;tr id=&quot;syntaxplugin_code_and_gutter&quot;&gt;
						&lt;td  style=&quot; line-height: 1.4em !important; padding: 0em; vertical-align: top;&quot;&gt;
					&lt;pre style=&quot;font-size: 1em; margin: 0 10px;  margin-top: 10px;   margin-bottom: 10px;  width: auto; padding: 0;&quot;&gt;&lt;span style=&quot;color: black; font-family: &apos;Consolas&apos;, &apos;Bitstream Vera Sans Mono&apos;, &apos;Courier New&apos;, Courier, monospace !important;&quot;&gt;{$or: [{a: 1, b: 1}, {a: 2, b: 2}]}&lt;/span&gt;&lt;/pre&gt;
			&lt;/td&gt;
		&lt;/tr&gt;
			&lt;/tbody&gt;
&lt;/table&gt;
&lt;/div&gt;
&lt;p/&gt;

&lt;p&gt;This rewrite involves distributing any predicates outside the contained &lt;tt&gt;$or&lt;/tt&gt; into each &lt;tt&gt;$or&lt;/tt&gt; clause. For example:&lt;/p&gt;

&lt;p/&gt;
&lt;div id=&quot;syntaxplugin&quot; class=&quot;syntaxplugin&quot; style=&quot;border: 1px dashed #bbb; border-radius: 5px !important; overflow: auto; max-height: 30em;&quot;&gt;
&lt;table cellspacing=&quot;0&quot; cellpadding=&quot;0&quot; border=&quot;0&quot; width=&quot;100%&quot; style=&quot;font-size: 1em; line-height: 1.4em !important; font-weight: normal; font-style: normal; color: black;&quot;&gt;
		&lt;tbody &gt;
				&lt;tr id=&quot;syntaxplugin_code_and_gutter&quot;&gt;
						&lt;td  style=&quot; line-height: 1.4em !important; padding: 0em; vertical-align: top;&quot;&gt;
					&lt;pre style=&quot;font-size: 1em; margin: 0 10px;  margin-top: 10px;   margin-bottom: 10px;  width: auto; padding: 0;&quot;&gt;&lt;span style=&quot;color: black; font-family: &apos;Consolas&apos;, &apos;Bitstream Vera Sans Mono&apos;, &apos;Courier New&apos;, Courier, monospace !important;&quot;&gt;{a: 1, b: 1, $or: [{c: 1}, {d: 1}]}&lt;/span&gt;&lt;/pre&gt;
			&lt;/td&gt;
		&lt;/tr&gt;
			&lt;/tbody&gt;
&lt;/table&gt;
&lt;/div&gt;
&lt;p/&gt;

&lt;p&gt;could become the following equivalent query:&lt;/p&gt;

&lt;p/&gt;
&lt;div id=&quot;syntaxplugin&quot; class=&quot;syntaxplugin&quot; style=&quot;border: 1px dashed #bbb; border-radius: 5px !important; overflow: auto; max-height: 30em;&quot;&gt;
&lt;table cellspacing=&quot;0&quot; cellpadding=&quot;0&quot; border=&quot;0&quot; width=&quot;100%&quot; style=&quot;font-size: 1em; line-height: 1.4em !important; font-weight: normal; font-style: normal; color: black;&quot;&gt;
		&lt;tbody &gt;
				&lt;tr id=&quot;syntaxplugin_code_and_gutter&quot;&gt;
						&lt;td  style=&quot; line-height: 1.4em !important; padding: 0em; vertical-align: top;&quot;&gt;
					&lt;pre style=&quot;font-size: 1em; margin: 0 10px;  margin-top: 10px;   margin-bottom: 10px;  width: auto; padding: 0;&quot;&gt;&lt;span style=&quot;color: black; font-family: &apos;Consolas&apos;, &apos;Bitstream Vera Sans Mono&apos;, &apos;Courier New&apos;, Courier, monospace !important;&quot;&gt;{$or: [{a: 1, b:1, c: 1}, {a: 1, b: 1, d: 1}]}&lt;/span&gt;&lt;/pre&gt;
			&lt;/td&gt;
		&lt;/tr&gt;
			&lt;/tbody&gt;
&lt;/table&gt;
&lt;/div&gt;
&lt;p/&gt;

&lt;p&gt;&lt;b&gt;AFFECTED VERSIONS&lt;/b&gt;&lt;/p&gt;

&lt;p&gt;MongoDB 2.6.0 through 3.5.3&lt;/p&gt;

&lt;p&gt;&lt;b&gt;FIX VERSION&lt;/b&gt; &lt;br/&gt;
The fix is included in the 3.5.4 development release. &lt;/p&gt;
&lt;/div&gt;&lt;/div&gt;

&lt;h6&gt;&lt;a name=&quot;Originaldescription&quot;&gt;&lt;/a&gt;Original description&lt;/h6&gt;

&lt;p&gt;Certain types of queries containing $or clauses no longer make efficient use of indexes.  This is a regression from 2.4 =&amp;gt; 2.6.&lt;/p&gt;

&lt;p&gt;Given a collection with indexes {a:1, b:1} and {a:1, c:1}, consider the following query:&lt;/p&gt;

&lt;p/&gt;
&lt;div id=&quot;syntaxplugin&quot; class=&quot;syntaxplugin&quot; style=&quot;border: 1px dashed #bbb; border-radius: 5px !important; overflow: auto; max-height: 30em;&quot;&gt;
&lt;table cellspacing=&quot;0&quot; cellpadding=&quot;0&quot; border=&quot;0&quot; width=&quot;100%&quot; style=&quot;font-size: 1em; line-height: 1.4em !important; font-weight: normal; font-style: normal; color: black;&quot;&gt;
		&lt;tbody &gt;
				&lt;tr id=&quot;syntaxplugin_code_and_gutter&quot;&gt;
						&lt;td  style=&quot; line-height: 1.4em !important; padding: 0em; vertical-align: top;&quot;&gt;
					&lt;pre style=&quot;font-size: 1em; margin: 0 10px;  margin-top: 10px;   margin-bottom: 10px;  width: auto; padding: 0;&quot;&gt;&lt;span style=&quot;color: black; font-family: &apos;Consolas&apos;, &apos;Bitstream Vera Sans Mono&apos;, &apos;Courier New&apos;, Courier, monospace !important;&quot;&gt;db.collection.find({a:1, $or: [{b:1}, {c:1}]})&lt;/span&gt;&lt;/pre&gt;
			&lt;/td&gt;
		&lt;/tr&gt;
			&lt;/tbody&gt;
&lt;/table&gt;
&lt;/div&gt;
&lt;p/&gt;

&lt;p&gt;The 2.4 query planner considers a union of an scan on index {a:1, b:1} with a scan on index {a:1, c:1}.&lt;/p&gt;

&lt;p&gt;The 2.6 query planner does not consider this plan; it selects a plan that scans the whole {a:1} range for one of the two indexes.&lt;/p&gt;

&lt;p&gt;There is an available workaround for this issue, which is to rewrite the query as a rooted $or (e.g. {$or: [{a:1, b:1}, {a:1, c:1}]}).  For these queries, the 2.6 query planner correctly considers a plan that performs a union of the separate index scans.&lt;/p&gt;</description>
                <environment></environment>
        <key id="133270">SERVER-13732</key>
            <summary>Predicates in top-level implicit AND query not considered when generating index access plan for contained OR</summary>
                <type id="1" iconUrl="https://jira.mongodb.org/secure/viewavatar?size=xsmall&amp;avatarId=14703&amp;avatarType=issuetype">Bug</type>
                                            <priority id="2" iconUrl="https://jira.mongodb.org/images/icons/priorities/critical.svg">Critical - P2</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="tess.avitabile@mongodb.com">Tess Avitabile</assignee>
                                    <reporter username="rassi">J Rassi</reporter>
                        <labels>
                            <label>2426</label>
                            <label>todo_in_code</label>
                    </labels>
                <created>Fri, 25 Apr 2014 02:41:07 +0000</created>
                <updated>Fri, 27 Sep 2019 18:41:46 +0000</updated>
                            <resolved>Tue, 28 Feb 2017 15:09:37 +0000</resolved>
                                    <version>2.6.0</version>
                                    <fixVersion>3.5.4</fixVersion>
                                    <component>Querying</component>
                                        <votes>18</votes>
                                    <watches>50</watches>
                                                                                                                <comments>
                            <comment id="1502069" author="xgen-internal-githook" created="Fri, 17 Feb 2017 14:58:39 +0000"  >&lt;p&gt;Author:&lt;/p&gt;
{u&apos;username&apos;: u&apos;tessavitabile&apos;, u&apos;name&apos;: u&apos;Tess Avitabile&apos;, u&apos;email&apos;: u&apos;tess.avitabile@mongodb.com&apos;}
&lt;p&gt;Message: &lt;a href=&quot;https://jira.mongodb.org/browse/SERVER-13732&quot; title=&quot;Predicates in top-level implicit AND query not considered when generating index access plan for contained OR&quot; class=&quot;issue-link&quot; data-issue-key=&quot;SERVER-13732&quot;&gt;&lt;del&gt;SERVER-13732&lt;/del&gt;&lt;/a&gt; Index access plan for contained OR should consider top-level predicates&lt;br/&gt;
Branch: master&lt;br/&gt;
&lt;a href=&quot;https://github.com/mongodb/mongo/commit/f77527a942347313e2848e050e89480bc3cadb95&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;https://github.com/mongodb/mongo/commit/f77527a942347313e2848e050e89480bc3cadb95&lt;/a&gt;&lt;/p&gt;</comment>
                            <comment id="1019522" author="xgen-internal-githook" created="Tue, 1 Sep 2015 16:07:29 +0000"  >&lt;p&gt;Author:&lt;/p&gt;
{u&apos;username&apos;: u&apos;dstorch&apos;, u&apos;name&apos;: u&apos;David Storch&apos;, u&apos;email&apos;: u&apos;david.storch@10gen.com&apos;}
&lt;p&gt;Message: &lt;a href=&quot;https://jira.mongodb.org/browse/SERVER-13732&quot; title=&quot;Predicates in top-level implicit AND query not considered when generating index access plan for contained OR&quot; class=&quot;issue-link&quot; data-issue-key=&quot;SERVER-13732&quot;&gt;&lt;del&gt;SERVER-13732&lt;/del&gt;&lt;/a&gt; disable subplanning for contained $or queries&lt;br/&gt;
Branch: master&lt;br/&gt;
&lt;a href=&quot;https://github.com/mongodb/mongo/commit/8fde29a7afd0c4fd5cc84ff4f03217f3efe224e1&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;https://github.com/mongodb/mongo/commit/8fde29a7afd0c4fd5cc84ff4f03217f3efe224e1&lt;/a&gt;&lt;/p&gt;</comment>
                            <comment id="1019519" author="david.storch" created="Tue, 1 Sep 2015 16:06:29 +0000"  >&lt;p&gt;Hi all,&lt;/p&gt;

&lt;p&gt;After reviewing the fix for this problem included in development release 3.1.6, we have decided that its risks outweigh its benefits. Unfortunately the fix results in a substantial performance regression in the query planner and introduces some fragile logic to the $or query execution machinery. Furthermore, the problem has a relatively straightforward application-level workaround. For these reasons, we are hesitant to include the fix in a stable release. We are disabling the codepath implementing the fix, re-opening this ticket, and refraining from pushing a backport to the 3.0.x stable release series. (Note that although the fix is disabled, we are leaving all the plumbing in place so that enabling in a future release is trivial, should the fix prove to be safe and the performance regression prove to have a minimal impact.)&lt;/p&gt;

&lt;p&gt;Our apologies for not fixing this. Please feel free to reach out to me on this ticket with questions or concerns.&lt;/p&gt;

&lt;p&gt;Best,&lt;br/&gt;
Dave&lt;/p&gt;</comment>
                            <comment id="963636" author="xgen-internal-githook" created="Fri, 10 Jul 2015 21:13:00 +0000"  >&lt;p&gt;Author:&lt;/p&gt;
{u&apos;username&apos;: u&apos;dstorch&apos;, u&apos;name&apos;: u&apos;David Storch&apos;, u&apos;email&apos;: u&apos;david.storch@10gen.com&apos;}
&lt;p&gt;Message: &lt;a href=&quot;https://jira.mongodb.org/browse/SERVER-13732&quot; title=&quot;Predicates in top-level implicit AND query not considered when generating index access plan for contained OR&quot; class=&quot;issue-link&quot; data-issue-key=&quot;SERVER-13732&quot;&gt;&lt;del&gt;SERVER-13732&lt;/del&gt;&lt;/a&gt; rewrite contained $or queries to rooted $or in the SubplanStage&lt;/p&gt;

&lt;p&gt;This allows queries with an $or contained within an explicit or implicit $and to be answered with&lt;br/&gt;
more efficient plans. It also expands the use of the SubplanStage to include contained $or queries&lt;br/&gt;
and therefore may reduce the number of plans considered for these queries.&lt;br/&gt;
Branch: master&lt;br/&gt;
&lt;a href=&quot;https://github.com/mongodb/mongo/commit/15c72c8570c63e2e6ba0a3d339a8286d0be604db&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;https://github.com/mongodb/mongo/commit/15c72c8570c63e2e6ba0a3d339a8286d0be604db&lt;/a&gt;&lt;/p&gt;</comment>
                            <comment id="789124" author="urs.enke" created="Thu, 18 Dec 2014 00:03:34 +0000"  >&lt;p&gt;You&apos;re right &#8211; I had mistyped.&lt;/p&gt;

&lt;p&gt;Of course, $in is only an alternative when the $or concerns a single field (or when all combinations of the affected fields&apos; values are allowed, so each field could get its own $in without changing the meaning). But whoever is used to MySQL&apos;s comparable performance of &quot;b=1 OR b=2&quot; and &quot;b IN (1,2)&quot; could easily assume a suitably simply structured $or to be optimized to use an index, despite the posibility of using the operator in a way that would be harder to optimize.&lt;/p&gt;</comment>
                            <comment id="789071" author="asya" created="Wed, 17 Dec 2014 23:26:46 +0000"  >&lt;p&gt;I believe you mean {&lt;tt&gt;a:1,$or:[{b:1},{b:2}]&lt;/tt&gt;} correct?&lt;/p&gt;

&lt;p&gt;The issue is when the two queries within $or do not test the same field - then they cannot be rewritten using $in.&lt;/p&gt;</comment>
                            <comment id="788088" author="urs.enke" created="Wed, 17 Dec 2014 11:02:55 +0000"  >&lt;p&gt;A small note: Queries like &lt;p/&gt;
&lt;div id=&quot;syntaxplugin&quot; class=&quot;syntaxplugin&quot; style=&quot;border: 1px dashed #bbb; border-radius: 5px !important; overflow: auto; max-height: 30em;&quot;&gt;
&lt;table cellspacing=&quot;0&quot; cellpadding=&quot;0&quot; border=&quot;0&quot; width=&quot;100%&quot; style=&quot;font-size: 1em; line-height: 1.4em !important; font-weight: normal; font-style: normal; color: black;&quot;&gt;
		&lt;tbody &gt;
				&lt;tr id=&quot;syntaxplugin_code_and_gutter&quot;&gt;
						&lt;td  style=&quot; line-height: 1.4em !important; padding: 0em; vertical-align: top;&quot;&gt;
					&lt;pre style=&quot;font-size: 1em; margin: 0 10px;  margin-top: 10px;   margin-bottom: 10px;  width: auto; padding: 0;&quot;&gt;&lt;span style=&quot;color: black; font-family: &apos;Consolas&apos;, &apos;Bitstream Vera Sans Mono&apos;, &apos;Courier New&apos;, Courier, monospace !important;&quot;&gt;{a:1, $or:[{b:1},{b:2}]}&lt;/span&gt;&lt;/pre&gt;
			&lt;/td&gt;
		&lt;/tr&gt;
			&lt;/tbody&gt;
&lt;/table&gt;
&lt;/div&gt;
&lt;p/&gt; could be rewritten as (or executed like) &lt;p/&gt;
&lt;div id=&quot;syntaxplugin&quot; class=&quot;syntaxplugin&quot; style=&quot;border: 1px dashed #bbb; border-radius: 5px !important; overflow: auto; max-height: 30em;&quot;&gt;
&lt;table cellspacing=&quot;0&quot; cellpadding=&quot;0&quot; border=&quot;0&quot; width=&quot;100%&quot; style=&quot;font-size: 1em; line-height: 1.4em !important; font-weight: normal; font-style: normal; color: black;&quot;&gt;
		&lt;tbody &gt;
				&lt;tr id=&quot;syntaxplugin_code_and_gutter&quot;&gt;
						&lt;td  style=&quot; line-height: 1.4em !important; padding: 0em; vertical-align: top;&quot;&gt;
					&lt;pre style=&quot;font-size: 1em; margin: 0 10px;  margin-top: 10px;   margin-bottom: 10px;  width: auto; padding: 0;&quot;&gt;&lt;span style=&quot;color: black; font-family: &apos;Consolas&apos;, &apos;Bitstream Vera Sans Mono&apos;, &apos;Courier New&apos;, Courier, monospace !important;&quot;&gt;{a:1, b:{$in:[1,2]}}&lt;/span&gt;&lt;/pre&gt;
			&lt;/td&gt;
		&lt;/tr&gt;
			&lt;/tbody&gt;
&lt;/table&gt;
&lt;/div&gt;
&lt;p/&gt;, which may be more efficient than changing anything at the root. One could argue that in such cases it&apos;s the user&apos;s job to use $in, but (s)he may expect $or to be an efficient choice as well given that it is when used at the root.&lt;/p&gt;</comment>
                            <comment id="724723" author="david.storch" created="Tue, 23 Sep 2014 03:34:33 +0000"  >&lt;p&gt;Hi all,&lt;/p&gt;

&lt;p&gt;A quick status update on this ticket follows.&lt;/p&gt;

&lt;p&gt;We have explored two options for solving this issue on the 2.6 branch:&lt;/p&gt;

&lt;ul&gt;
	&lt;li&gt;Introduce a logical rewrite that rearranges the abstract syntax tree into a rooted-$or.&lt;/li&gt;
	&lt;li&gt;Alter our exploration of the plan space so that it is capable of enumerating the missed access plans.&lt;/li&gt;
&lt;/ul&gt;


&lt;p&gt;After technical review, both of these solutions were deemed to be a step in the wrong direction. The system does not currently have a rewrite engine. Doing this particular logical rewrite breaks some internal assumptions (for instance, the update system&apos;s logic for computing the document to insert on {upsert: true} updates depends on the absence of any logical rewrites). Furthermore, this change would improve the plans for one class of queries at the expense of another class.&lt;/p&gt;

&lt;p&gt;Regarding the plan space exploration solution: moving forward we hope to alter our exploration strategy in order to be more flexible about which plans we consider and which we don&apos;t. Using the current strategy for exploring the plan space, this change is technically difficult if not infeasible.&lt;/p&gt;

&lt;p&gt;For the reasons listed above, backport to the 2.6 branch is currently not planned.&lt;/p&gt;

&lt;p&gt;Best,&lt;br/&gt;
Dave&lt;/p&gt;</comment>
                            <comment id="562478" author="rassi@10gen.com" created="Fri, 25 Apr 2014 02:43:56 +0000"  >&lt;p&gt;Further detail follows.&lt;/p&gt;

&lt;p&gt;In version 2.4 and earlier: for specific classes of queries containing $or clauses, the query planner would consider a plan that unions index scans on separate indexes.  Queries that qualified include:&lt;/p&gt;

&lt;ol&gt;
	&lt;li&gt;queries rooted at an $or
	&lt;ul&gt;
		&lt;li&gt;e.g. for the query {$or: [{b:1}, {c:1}]}, the planner would consider a union of a scan on index {b:1} with a scan on index {c:1}&lt;/li&gt;
	&lt;/ul&gt;
	&lt;/li&gt;
	&lt;li&gt;queries rooted at an implicit $and that have an $or child
	&lt;ul&gt;
		&lt;li&gt;e.g. for the query {a:1, $or: [{b:1}, {c:1}]}, the planner would additionally consider a union of a scan on index {a:1, b:1} with a scan on index {a:1, c:1}&lt;/li&gt;
	&lt;/ul&gt;
	&lt;/li&gt;
&lt;/ol&gt;


&lt;p&gt;For all other queries containing an $or clause, the 2.4 query planner would not consider assigning indexes to the $or child predicates.&lt;/p&gt;

&lt;p&gt;In version 2.6.0: the query planner always considers an indexed plan for $or, but the indexes chosen for the union are only based on the predicates contained in the $or children.  That is, when planning the query {a:1, $or: [{b:1}, {c:1}]}, the 2.6 query planner will not consider the {a:1} predicate when creating a plan that takes a union of separate indexes.  Employing the workaround (that is, rewriting the query as {$or: [{a:1, b:1}, {a:1, c:1}]}) allows both predicates to be used.&lt;/p&gt;</comment>
                    </comments>
                <issuelinks>
                            <issuelinktype id="10011">
                    <name>Depends</name>
                                            <outwardlinks description="depends on">
                                                        </outwardlinks>
                                                                <inwardlinks description="is depended on by">
                                                        </inwardlinks>
                                    </issuelinktype>
                            <issuelinktype id="10010">
                    <name>Duplicate</name>
                                                                <inwardlinks description="is duplicated by">
                                        <issuelink>
            <issuekey id="273918">SERVER-23251</issuekey>
        </issuelink>
            <issuelink>
            <issuekey id="287894">SERVER-24209</issuekey>
        </issuelink>
            <issuelink>
            <issuekey id="306519">SERVER-25442</issuekey>
        </issuelink>
            <issuelink>
            <issuekey id="457690">SERVER-31929</issuekey>
        </issuelink>
            <issuelink>
            <issuekey id="139593">SERVER-14130</issuekey>
        </issuelink>
                            </inwardlinks>
                                    </issuelinktype>
                            <issuelinktype id="10012">
                    <name>Related</name>
                                            <outwardlinks description="related to">
                                        <issuelink>
            <issuekey id="580891">SERVER-36393</issuekey>
        </issuelink>
            <issuelink>
            <issuekey id="475322">SERVER-32441</issuekey>
        </issuelink>
            <issuelink>
            <issuekey id="154481">SERVER-15012</issuekey>
        </issuelink>
            <issuelink>
            <issuekey id="118919">SERVER-13104</issuekey>
        </issuelink>
            <issuelink>
            <issuekey id="150198">SERVER-14740</issuekey>
        </issuelink>
            <issuelink>
            <issuekey id="351478">SERVER-27904</issuekey>
        </issuelink>
            <issuelink>
            <issuekey id="881107">SERVER-42558</issuekey>
        </issuelink>
            <issuelink>
            <issuekey id="207697">SERVER-18777</issuekey>
        </issuelink>
                            </outwardlinks>
                                                                <inwardlinks description="is related to">
                                        <issuelink>
            <issuekey id="120171">SERVER-13184</issuekey>
        </issuelink>
            <issuelink>
            <issuekey id="157540">SERVER-15208</issuekey>
        </issuelink>
            <issuelink>
            <issuekey id="216714">SERVER-19388</issuekey>
        </issuelink>
            <issuelink>
            <issuekey id="433401">SERVER-31280</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>9.0</customfieldvalue>
                        </customfieldvalues>
                    </customfield>
                                                                <customfield id="customfield_18555" key="com.onresolve.jira.groovy.groovyrunner:scripted-field">
                        <customfieldname># of Sprints</customfieldname>
                        <customfieldvalues>
                            <customfieldvalue>7.0</customfieldvalue>

                        </customfieldvalues>
                    </customfield>
                                                                                                                                                                                                                                                                                                                                                                                                                                            <customfield id="customfield_10011" key="com.atlassian.jira.plugin.system.customfieldtypes:radiobuttons">
                        <customfieldname>Backwards Compatibility</customfieldname>
                        <customfieldvalues>
                                <customfieldvalue key="10038"><![CDATA[Fully Compatible]]></customfieldvalue>

                        </customfieldvalues>
                    </customfield>
                                                                                                                                                    <customfield id="customfield_13552" key="com.go2group.jira.plugin.crm:crm_generic_field">
                        <customfieldname>Case</customfieldname>
                        <customfieldvalues>
                            <customfieldvalue><![CDATA[[500A000000VDqaOIAT, 500A000000VXwrcIAD, 500A000000UaYOoIAN, 500A000000UaZoPIAV, 500A000000UaYb9IAF, 500A000000ZQQ55IAH, 500A000000aA2KyIAK, 500A000000aNoaeIAC, 500A000000aO45DIAS, 500A000000arUcOIAU, 500A000000bUgIRIA0, 500A000000byGHYIA2, 5002K00000cyAorQAE, 5002K00000dafTSQAY]]]></customfieldvalue>

                        </customfieldvalues>
                    </customfield>
                                                                                                                                                                                                                                                                                                                            <customfield id="customfield_10055" key="com.atlassian.jira.ext.charting:firstresponsedate">
                        <customfieldname>Date of 1st Reply</customfieldname>
                        <customfieldvalues>
                            <customfieldvalue>Wed, 27 Aug 2014 16:09:37 +0000</customfieldvalue>

                        </customfieldvalues>
                    </customfield>
                                                                <customfield id="customfield_10052" key="com.atlassian.jira.toolkit:dayslastcommented">
                        <customfieldname>Days since reply</customfieldname>
                        <customfieldvalues>
                                        6 years, 51 weeks, 5 days ago
    
                        </customfieldvalues>
                    </customfield>
                                                                <customfield id="customfield_18254" key="com.onresolve.jira.groovy.groovyrunner:scripted-field">
                        <customfieldname>Dependencies</customfieldname>
                        <customfieldvalues>
                            <customfieldvalue><![CDATA[<s><a href='https://jira.mongodb.org/browse/WRITING-1377'>WRITING-1377</a></s>, <s><a href='https://jira.mongodb.org/browse/CS-30518'>CS-30518</a></s>]]></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_10857" key="com.pyxis.greenhopper.jira:gh-epic-link">
                        <customfieldname>Epic Link</customfieldname>
                        <customfieldvalues>
                            <customfieldvalue>PM-614</customfieldvalue>
                        </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>carl.champain@mongodb.com</customfieldvalue>

                        </customfieldvalues>
                    </customfield>
                                                                <customfield id="customfield_11151" key="com.atlassian.jira.toolkit:LastCommentDate">
                        <customfieldname>Last public comment date</customfieldname>
                        <customfieldvalues>
                            6 years, 51 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_10032" key="com.atlassian.jira.plugin.system.customfieldtypes:select">
                        <customfieldname>Operating System</customfieldname>
                        <customfieldvalues>
                                <customfieldvalue key="10026"><![CDATA[ALL]]></customfieldvalue>

                        </customfieldvalues>
                    </customfield>
                                                                                                                                                                                <customfield id="customfield_10051" key="com.atlassian.jira.toolkit:participants">
                        <customfieldname>Participants</customfieldname>
                        <customfieldvalues>
                                        <customfieldvalue>asya.kamsky@mongodb.com</customfieldvalue>
            <customfieldvalue>david.storch@mongodb.com</customfieldvalue>
            <customfieldvalue>xgen-internal-githook</customfieldvalue>
            <customfieldvalue>rassi</customfieldvalue>
            <customfieldvalue>tess.avitabile@mongodb.com</customfieldvalue>
            <customfieldvalue>urs.enke</customfieldvalue>
    
                        </customfieldvalues>
                    </customfield>
                                                                                                                                                                                                                                        <customfield id="customfield_14254" key="com.pyxis.greenhopper.jira:gh-lexo-rank">
                        <customfieldname>Product Rank</customfieldname>
                        <customfieldvalues>
                            <customfieldvalue>1|hrlw3b:</customfieldvalue>

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

                        </customfieldvalues>
                    </customfield>
                                                                <customfield id="customfield_10558" key="com.pyxis.greenhopper.jira:gh-global-rank">
                        <customfieldname>Rank (Obsolete)</customfieldname>
                        <customfieldvalues>
                            <customfieldvalue>114509</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_10557" key="com.pyxis.greenhopper.jira:gh-sprint">
                        <customfieldname>Sprint</customfieldname>
                        <customfieldvalues>
                                <customfieldvalue id="490">Quint Iteration 3</customfieldvalue>
    <customfieldvalue id="518">Quint Iteration 4</customfieldvalue>
    <customfieldvalue id="536">Quint Iteration 5</customfieldvalue>
    <customfieldvalue id="572">Quint Iteration 6</customfieldvalue>
    <customfieldvalue id="1438">Query 2017-01-23</customfieldvalue>
    <customfieldvalue id="1465">Query 2017-02-13</customfieldvalue>
    <customfieldvalue id="1570">Query 2017-03-06</customfieldvalue>

                        </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_11861" key="com.atlassian.jira.plugin.system.customfieldtypes:radiobuttons">
                        <customfieldname>User Summary</customfieldname>
                        <customfieldvalues>
                                <customfieldvalue key="11857"><![CDATA[Requested]]></customfieldvalue>

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

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