RavenDB 4.1 FeaturesExplain that choice
One of the things that we do in RavenDB is try to expose as much as possible the internal workings and logic inside RavenDB. In this case, the relevant feature we are trying to expose is the inner working of the query optimizer.
Consider the following query, running on a busy system.
This will go to query optimizer, that needs to select the appropriate index to run this query on. However, this process is somewhat of a black box from the outside. Let me show you how RavenDB externalize that decision.
You can see that there were initially three index candidates for this. The first one doesn’t index FirstName, so it was ruled out immediately. That gave us a choice of two suitable indexes.
The query optimizer selected the index that has the higher number of fields. This is done to route queries from narrower indexes so they will be retired sooner.
This is a simple case, there are many other factors that may play into the query optimizer decision, such as when an index is stale because it was just created. The query optimizer will then choose another index until the stale index catch up with all its work.
To be honest, I mostly expect this to be of use when we explain how the query optimizer work. Of course, if you are investigating “why did you use this index and not that one” in production, this feature is going to be invaluable.
More posts in "RavenDB 4.1 Features" series:
- (22 Aug 2018) MongoDB & CosmosDB Migration Wizards
- (04 Jul 2018) This document is included in your subscription
- (03 Jul 2018) Detailed query timing details
- (02 Jul 2018) Of course I know ya, dude
- (29 Jun 2018) Running RavenDB embedded
- (26 Jun 2018) Can you explain that choice?
- (20 Jun 2018) Cluster wide ACID transactions
- (19 Jun 2018) Explain that choice
- (22 May 2018) Highlighting
- (11 May 2018) Counting my counters
- (10 May 2018) JavaScript Indexes
- (04 May 2018) SQL Migration Wizard
Comments
Somehow choosing the most unstable index sounds bad as a preferece. Maybe it's just that I don't like unstable things.
Marko, Did you switch
stable
andstale
? The query optimizer chose the most unstale index. In other words, the one that is most up to date.Oren, the screenshot does say "unstable". Is that a typo?
Svick, Yes, it is. I'll fix that in the code.
Oren, I was so impressed by this feature that I've posted it to the SQL Server user voice site as a feature request =) You can read about it on my new blog here: http://joshthecoder.com/2018/06/21/feature-request-index-rejection-reasons.html
jadarnel27, This is pretty cool.
Comment preview