Now we had a detailed look at what indexes do and how you can create your own indexes and I can only
encourage you to play around with that to get a better feeling for your different options and how indexes
work
but in order to play around and to understand if an index is worth the effort, you need to know how to
diagnose your queries and I already did show you the explain method for this.
The important part here is that you can execute it like this or pass query planner as an argument to
get that default minimal output where it simply tells you the winning plan and not much else.
Or you use execution stats, what
we did a couple of times in this module already to see detailed summary outputs and see information
about the winning plan and possibly rejected plan and also some information about how long it took.
There also is the all plans execution option which also show shows detailed summaries and which also
gives you more information about how the winning plan was chosen.
Now we'll have a look at all three of them throughout this module again. For determining whether a query is efficient,
it's obviously interesting to look at the milliseconds process time and also compare this to a solution
where you don't use an index, so that you'll also have a look whether index scan really beats a collection
scan which it typically does though
but I did already show you some use cases in cases where you fetch almost everything where the index
scan can be slower
and another important measure is that you compare the number of keys in the index, that is what it means
in the output are examined, how many documents that are examined and how many documents that are returned
and the keys and document should be close together and documents or documents, examine the documents returned
should be closed or documents should be zero so that it looked at zero documents
and when would this be the case? In a so-called covered query
and now what is a covered query?
Well let me show it to you.