Cosmos charges and documentation seem to be all over the place.

[MacMcDell]

Our cosmos charges are going off the rails so we looked into trying to manage these charges better. We were going off the following documentation to attempt to get things under control. https://learn.microsoft.com/en-us/azure/cosmos-db/nosql/how-to-dotnet-read-item. Within the documentation it states that using 'ReadManyItemsAsync' would be our cheapest option where requesting multiple items back from the collection. Our current implementation is using the 'GetItemLingQueryable'. https://docs.microsoft.com/azure/cosmos-db/sql-query-linq-to-sql

In order to test these theories, we benchmarked our original response from cosmos container...Sending 25 items that contain both the partition and ids returns us an IOrderedQueryable collection of 25 items. The total request charge is 6.75 RU.

Next Test:
Within the same method we then called the ReadManyItems and, (sending both partition[] and Ids[]) we get back the same collection of 25 items in the roughly the same amount of time +- a few ms ... but this time the cost is 9.05 RU! ??

Using the recommended 'cheaper' and 'faster' method seems to overall cost us 30% more than using the linq iterrator?? Why?
This is extremely troubling as it seems very misleading from a documentation perspective we are being recommended to use a baked in method but in reality it is 30% more overall.

A rough example of our test code is below:

          sw.Restart();
            var container = _dbContext.Database.GetContainer(CollectionName);
            var query = container.GetItemLinqQueryable<SensorData>(
                requestOptions:  new QueryRequestOptions { EnableScanInQuery = true, MaxConcurrency = -1, MaxBufferedItemCount = -1, MaxItemCount = -1 });

            var filteredQuery = query.Where(s => partitionKeys.Contains(s.PartitionKey) && sensorIds.Contains(s.Id)) ; //<<<the query contains items that only have partition and ids. 
            var iterator = filteredQuery.ToFeedIterator();
            var results = new List<SensorData>();
            double totalRequestCharge = 0;
            while (iterator.HasMoreResults)
            {
                var response = await iterator.ReadNextAsync(cancellationToken);
                results.AddRange(response);
                totalRequestCharge += response.RequestCharge;
            }

            //var oldcode  = await GetAsync(s => partitionKeys.Contains(s.PartitionKey) && sensorIds.Contains(s.Id), null, CancellationToken.None);
            _logger.LogCritical($" original: {sw.ElapsedMilliseconds.ToString()}");

            

            sw.Restart();
            // _logger.LogWarning("ReadManyItems");
            var result = await
                _dbContext.ReadManyItemsAsync<SensorData>(CollectionName, sensorIds.ToList(),  partitionKeys.ToList());
            _logger.LogCritical($" read many items: {sw.ElapsedMilliseconds.ToString()}");
            return result; 

It would be nice to know what the correct thing to do in the case of:

• GIVEN we have 25 records we need to retrieve from Cosmos.
• AND we have the partition and id of each of those 25 items
• WHEN we want the collection back
• THEN the most efficient and cost effective query is performed

Any help of advice would be appreciated. We use IOT devices so we are hitting Cosmos thousands of times an hour. Cutting down any of our cosmos costs is paramount to us.

[MacMcDell]

For further reference the original stack question is here:
https://stackoverflow.com/questions/74828204/why-does-readmanyitemsasync-perform-query-operation-when-ms-docs-says-it-doesnt
Moving it to a discussion as the documentation was changed to reflect the issue but doesn't dig into why other queries are clearly still cheaper overall.