You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Automatic indexing on each property is so powerful. I'm wondering if we can leverage this to efficiently fulfill "top N per group" queries without composite indexes, e.g. find all objects with a given groupKey value in order of creation. As an example of a groupKey, imagine a customer ID on invoice objects.
If I'm not mistaken, elements with the same groupKey value should be encountered in rid order, and rid order is practically creation order.
By that logic, ordering by groupKey, rid should require no sorting, even when no composite index exists for the pair. So long as groupKey is indexed, which by default it would be, we should be able to efficiently find the instances matching a given value, and we should encounter them in rid order. I'd reason that translates to ordering by groupKey DESC, rid DESC too, as well as to variants that constrain the rid to a specific range - basically anything you could do with an index on groupKey, rid.
Is this reasoning correct? Does CosmosDB work this way?
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
Automatic indexing on each property is so powerful. I'm wondering if we can leverage this to efficiently fulfill "top N per group" queries without composite indexes, e.g. find all objects with a given
groupKey
value in order of creation. As an example of agroupKey
, imagine a customer ID on invoice objects.If I'm not mistaken, elements with the same
groupKey
value should be encountered inrid
order, andrid
order is practically creation order.By that logic, ordering by
groupKey, rid
should require no sorting, even when no composite index exists for the pair. So long asgroupKey
is indexed, which by default it would be, we should be able to efficiently find the instances matching a given value, and we should encounter them inrid
order. I'd reason that translates to ordering bygroupKey DESC, rid DESC
too, as well as to variants that constrain therid
to a specific range - basically anything you could do with an index ongroupKey, rid
.Is this reasoning correct? Does CosmosDB work this way?
Beta Was this translation helpful? Give feedback.
All reactions