1
00:00:02,170 --> 00:00:05,050
Now that we had a look at the basics of indexes,

2
00:00:05,200 --> 00:00:11,740
it's also important to understand that indexes are not just there for finding but they can also help

3
00:00:11,740 --> 00:00:16,200
you with sorting because we have a sorted list of elements of the index right,

4
00:00:16,380 --> 00:00:21,490
mongodb can utilize that in case you want to sort in the same way that index list is sorted.

5
00:00:21,490 --> 00:00:31,310
So in our example here, I could find, whoops and I should explain this of course, so I could find let's

6
00:00:31,310 --> 00:00:40,450
say all people with an age of 35 and then sort with that sort

7
00:00:40,460 --> 00:00:46,140
operator and then sort for gender in an ascending order.

8
00:00:46,760 --> 00:00:53,820
If I execute this, you see that it did actually use an index scan for both gender and age,

9
00:00:53,840 --> 00:00:59,220
even though I only filtered by age but it used the gender information for the sorting.

10
00:00:59,240 --> 00:01:05,640
Now this is another cool feature of indexes, since we have an ordered list of values already, mongodb

11
00:01:05,650 --> 00:01:10,770
can utilize that to quickly give us back the order of documents we need.

12
00:01:10,850 --> 00:01:17,390
Now also important to understand or to know here is that if you are not using indexes and you do a sort

13
00:01:17,390 --> 00:01:23,060
on a large amount of documents, you can actually timeout because mongodb has a threshold of

14
00:01:23,150 --> 00:01:26,530
32 megabytes in memory for sorting

15
00:01:26,590 --> 00:01:31,760
and if you have no index, mongodb will essentially fetch all your documents into memory and do the

16
00:01:31,760 --> 00:01:32,760
sort there

17
00:01:32,930 --> 00:01:38,510
and for large collections and large amounts of fetched documents, this can simply be too much to then

18
00:01:38,510 --> 00:01:39,500
sort.

19
00:01:39,500 --> 00:01:44,900
So sometimes, you also need an index not just to speed up the query which always makes sense but also

20
00:01:44,900 --> 00:01:46,820
to be able to sort at all.

21
00:01:46,820 --> 00:01:52,010
Now this is not the case for our small dataset here but if you have millions of documents, you could

22
00:01:52,010 --> 00:01:57,190
very well have a query where you fetch so many documents that an in-memory sort which is the default

23
00:01:57,230 --> 00:02:01,310
then is just not possible and you need an index which is already sorted

24
00:02:01,400 --> 00:02:06,500
so that mongodb doesn't have to sort in memory but can just take the order you have in the index.

25
00:02:06,500 --> 00:02:10,970
So that's also something important to keep in mind that when you're sorting documents and you have

26
00:02:10,970 --> 00:02:16,370
a lot of documents at a given query, you might need an index to be able to sort them at all because

27
00:02:16,370 --> 00:02:22,700
mongodb has this threshold of 32 megabytes which it reserves in memory for the fetched documents

28
00:02:22,700 --> 00:02:23,390
and sorting them.