Open JoeSchimo opened 4 years ago
I encountered similar behavior, the issue might be localized in internal TableEntity implementation of Microsoft.Azure.Cosmos.Table package ( ReadEntity method)
As a workaround, i use another TableEntity class by overriding ReadEntity method. Its implementation was based on original Microsoft.WindowsAzure.Storage code.
All it's works very well but we still waiting for a fix
Related StackOverflow thread
I've been researching moving from Storage Account table storage to CosmosDB table storage. Currently I am using the WindowsAzure.Storage (9.3.3) library to query data in a .net core 3.1 application. As part of this migration I have switched to the Microsoft.Azure.Cosmos.Table 1.0.7 library. I wrote the LinqPad benchmark below to compare the performance of both when doing a full table scan.
The Storage Account table and CosmosDb table have an identical datasets of roughly 200k entities.
The Cosmos Table Account has a shared provision throughput of 2200 RUs.
When using the Cosmos Executor with the Microsoft.Azure.Cosmos.Table library I am getting an execution time of ~3 hours. The Storage Account table with the Microsoft.WindowsAzure.Storage library takes ~2 minutes. If I switch the Microsoft.Azure.Cosmos.Table library to use the rest executor in the Cloud Table Client I get an execution time of ~3 minutes.
Has anyone encountered similar behavior or aware of issues around empty table queries?