From 2679e87a8f0c841707ee79d8cb0b65c1d4e6f2ab Mon Sep 17 00:00:00 2001
From: Randall Hunt <randallhunt@gmail.com>
Date: Thu, 17 May 2012 23:43:19 -0400
Subject: [PATCH] changed significant to significantly

---
 ...2011-10-12-Speedig-Up-Queries-Understanding-Query-Plans.html | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/_posts/2011-10-12-Speedig-Up-Queries-Understanding-Query-Plans.html b/_posts/2011-10-12-Speedig-Up-Queries-Understanding-Query-Plans.html
index 4e6fb53..3c34f80 100644
--- a/_posts/2011-10-12-Speedig-Up-Queries-Understanding-Query-Plans.html
+++ b/_posts/2011-10-12-Speedig-Up-Queries-Understanding-Query-Plans.html
@@ -62,7 +62,7 @@ <h3>Field Order</h3>
     <div class="text">
       <p>The order of the fields used to create your index is critical. The good news is that, if you get the order wrong, the index won't be used at all, so it'll be easy to spot with <code>explain</code>.</p>
       <p>The queries on the right are two different queries. What's important though is that the first query cannot use the index because <code>cat</code> is defined first in our index. You should think of compound indexes as having the field values concatenated together. So, an "index value" of "book405" (cat + qty) can only be used to find something by cat <strong>or</strong> cat and qty.</p>
-      <p>The two queries return around the same number of documents, but the second, index-powered query, has to scan a significant smaller number of objects. This is due to the logarithmic nature of B-trees, which Mongo indexes use.</p>
+      <p>The two queries return around the same number of documents, but the second, index-powered query, has to scan a significantly smaller number of objects. This is due to the logarithmic nature of B-trees, which Mongo indexes use.</p>
     </div>
     <pre>db.products.createIndex({cat: 1, qty: 1})
 db.products.find({qty: {$gt: 400}}).explain()