Why does it cost so much more to sort Azure Cosmos queries by timestamp (string) than _ts (inline)?
This request costs 265 RU / s :
SELECT top 1 * FROM c
WHERE c.CollectPackageId = 'd0613cbb-492b-4464-b66b-3634b5571826'
ORDER BY c.StartFetchDateTimeUtc DESC
StartFetchDateTimeUtc is a string property serialized using the Cosmos API
This request costs 5 RU / s :
SELECT top 1 * FROM c
WHERE c.CollectPackageId = 'd0613cbb-492b-4464-b66b-3634b5571826'
ORDER BY c._ts DESC
_ts is a built-in field, a numeric label based on Unix.
Result result (including this field and _ts):
"StartFetchDateTimeUtc": "2017-08-08T03:35:04.1654152Z",
"_ts": 1502163306
The index is in place and follows the guidelines and tutorials on how to set up the sortable string / timestamp. It looks like:
{
"path": "/StartFetchDateTimeUtc/?",
"indexes": [
{
"kind": "Range",
"dataType": "String",
"precision": -1
}
]
}
source to share
According to this article , " size ", item property size, data consistency, indexed properties, document indexing, query templates, Script use variables affect RU.
So it's very strange that different properties cost different RU.
I am also creating a test demo on my side (with your index and the same document property). I have entered 1000 records in documentdb. Two different requests cost the same RU. I suggest you start a new collection again and test.
The result looks like this:
Order by StartFetchDateTimeUtc
Order by _ts
source to share