Why does a Azure Cosmos query sorting by timestamp (string) cost so much more than by _ts (built in)?

Viewed 1565

This query cost 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 by using the Cosmos API

This query cost 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 Unix-based numeric timestamp.

Example result (only including this field and _ts): "StartFetchDateTimeUtc": "2017-08-08T03:35:04.1654152Z", "_ts": 1502163306

The index is in place and follows the suggestions & tutorials how to configure a sortable string/timestamp. It looks like: { "path": "/StartFetchDateTimeUtc/?", "indexes": [ { "kind": "Range", "dataType": "String", "precision": -1 } ] }

1 Answers
Related