1
00:00:02,160 --> 00:00:07,860
Now we had a detailed look at what indexes do and how you can create your own indexes and I can only

2
00:00:07,860 --> 00:00:13,300
encourage you to play around with that to get a better feeling for your different options and how indexes

3
00:00:13,340 --> 00:00:13,960
work

4
00:00:14,130 --> 00:00:19,920
but in order to play around and to understand if an index is worth the effort, you need to know how to

5
00:00:19,920 --> 00:00:24,780
diagnose your queries and I already did show you the explain method for this.

6
00:00:24,810 --> 00:00:31,110
The important part here is that you can execute it like this or pass query planner as an argument to

7
00:00:31,110 --> 00:00:36,540
get that default minimal output where it simply tells you the winning plan and not much else.

8
00:00:37,110 --> 00:00:39,570
Or you use execution stats, what

9
00:00:39,630 --> 00:00:45,660
we did a couple of times in this module already to see detailed summary outputs and see information

10
00:00:45,660 --> 00:00:53,050
about the winning plan and possibly rejected plan and also some information about how long it took.

11
00:00:53,160 --> 00:01:00,840
There also is the all plans execution option which also show shows detailed summaries and which also

12
00:01:00,840 --> 00:01:05,670
gives you more information about how the winning plan was chosen.

13
00:01:05,670 --> 00:01:12,420
Now we'll have a look at all three of them throughout this module again. For determining whether a query is efficient,

14
00:01:12,630 --> 00:01:18,690
it's obviously interesting to look at the milliseconds process time and also compare this to a solution

15
00:01:18,690 --> 00:01:24,780
where you don't use an index, so that you'll also have a look whether index scan really beats a collection

16
00:01:24,780 --> 00:01:26,680
scan which it typically does though

17
00:01:26,730 --> 00:01:31,800
but I did already show you some use cases in cases where you fetch almost everything where the index

18
00:01:31,800 --> 00:01:33,540
scan can be slower

19
00:01:33,990 --> 00:01:40,080
and another important measure is that you compare the number of keys in the index, that is what it means

20
00:01:40,080 --> 00:01:47,050
in the output are examined, how many documents that are examined and how many documents that are returned

21
00:01:47,540 --> 00:01:53,610
and the keys and document should be close together and documents or documents, examine the documents returned

22
00:01:53,610 --> 00:01:59,760
should be closed or documents should be zero so that it looked at zero documents

23
00:01:59,940 --> 00:02:04,510
and when would this be the case? In a so-called covered query

24
00:02:04,530 --> 00:02:06,770
and now what is a covered query?

25
00:02:06,870 --> 00:02:07,870
Well let me show it to you.