title: Why does a Azure Cosmos query sorting by timestamp (string) cost so much more than by _ts (built in)?
body: <p><strong>This query cost 265 RU/s</strong>:
  <code>
  SELECT top 1 * FROM c 
  WHERE c.CollectPackageId = 'd0613cbb-492b-4464-b66b-3634b5571826'
  ORDER BY c.StartFetchDateTimeUtc DESC
  </code></p>
  
  <p><strong>StartFetchDateTimeUtc</strong> is a string property, serialized by using the Cosmos API</p>
  
  <p><strong>This query cost 5 RU/s</strong>:
  <code>
  SELECT top 1 * FROM c 
  WHERE c.CollectPackageId = 'd0613cbb-492b-4464-b66b-3634b5571826'
  ORDER BY c._ts DESC
  </code></p>
  
  <p><strong>_ts</strong> is a built in field, a Unix-based numeric timestamp.</p>
  
  <p><strong>Example result</strong> (only including this field and _ts):
  <code>
  "StartFetchDateTimeUtc": "2017-08-08T03:35:04.1654152Z",
  "_ts": 1502163306
  </code></p>
  
  <p><strong>The index</strong> is in place and follows the suggestions &amp; tutorials how to configure a sortable string/timestamp. It looks like:
  <code>
      {
        "path": "/StartFetchDateTimeUtc/?",
        "indexes": [
          {
            "kind": "Range",
            "dataType": "String",
            "precision": -1
          }
        ]
      }
  </code></p>