3 ms·

One way to approach a behind the curtain automatic index generation would be to gather data about collection usage, and use such data to enable targeted indexes

• arthurcolle 12y ago
  Forgive my ignorance but why would it scale geometrically? I tried to quickly think of a complexity analysis and I don't see where you are coming from.
  • andrea_s 12y ago
    Well, ordering matter in indexes - and clearly building a dedicated index for every field would not work, simplest queries aside. So if I have three fields - a, b and c - and by hypothesis I want to map all possible queries in a naive way, I will need to build, at the very least, the following indexes: [a, b, c] [a, c, b] [b, a, c] [b, c, a] [c, a, b] [c, b, a] all of which represent a different and valid way of querying my data. Anything less than this would leave some valid query uncovered by the indexes. These are 6 indexes, which is 3! (factorial). Add a fourth field and we have 12 indexes, and so on. Hence, geometrical growth (to be fair, factorial growth is even greater than geometrical). Which is why I'm thinking that either (i) indexes get created automatically based on the most frequent / heavy queries, or (ii) indexing works differently for DocumentDB and they are actually able to map the document space in a more efficient way (but I'd say that we lack the technical details to jump at this conclusion, at the moment).