https://comparisumzug.ch/

Thanks for compiling this! I now can use it successfully in Compass. However, because of using dynamic SearchDefinitionBuilder, I'm still waiting for C# driver support this option.

Thanks for this! I'm trying it but I'm getting the following error: "{{fieldName}} is not indexed as sortable." I already rebuilt the index. Is there something else I'm missing? The example in the documentation uses facet types, maybe that?

I need to sort based on timestamp, i tried near but it's not working { near: { path: "data.postingDate_timestamp", origin: 1686433743913, pivot: 1, score: { boost: { value: 1000, }, }, }, },

Cluster tier M30, Version 4.4.21. Atlas search collection.Aggregate().Search(Builders.Search.Compound().Must(clauses), indexName: "Dashboard-Index", returnStoredSource: true) .SortByDescending(x => x.LastUpdate).Skip(0).Limit(200).ToList(); Statistic: 19k ~ 9 seconds 98k ~ 7 seconds 149k ~ 19 seconds 231k ~ 69 seconds Too bad performance of sorting after search

Hi Admin, could you please share a high-level idea of the solution (that is currently being worked on) for faster sorting with Atlas search? This would help us understand if it would meet our requirements and/or if we need to make changes to our module that builds the queries. Thanks!

Any ETA on when faster sort inside Atlas search will be available? I have tried stored source and it has failed miserably for my requirement :(

Hello, Is there a ETA for this work to be completed ?

How is this different from having a project stage after $search, also this approach doesn't seems to improve the performance on lage dataset.

Having the the ability to sort big number of documents inside Atlas search is crucial. The alternative of using storedSource and sort stage after that is very slow and cannot be used in a user-facing application

While stored fields are definitely much faster than not using them, a $sort clause on a large result set is still way too slow (10 - 30 sec vs upwards of 90 sec+). The docs suggest that sorting can be done in $search, but does not show any examples of how. "Using a $sort aggregation pipeline stage after a $search stage can drastically slow down query results. If possible, design your $search query so that all necessary sorting occurs in the $search stage to remove the need for a $sort stage. ..."

This does not seem like an acceptable solution to the sort problem. Adding stored source is going to increase index overhead. It should use the already created field mappings and allow a native searchSort stage. I have also tried stored source on a collection of around 300k documents and it is still way too slow. (M40 cluster)

I've tried stored fields but it doesn't improve the performance of $sort or $skip to acceptable numbers on large data sets. Index definition:- { "mappings": { "dynamic": false, "fields": { "category": { "fields": { "name": { "store": false, "type": "string" } }, "type": "document" }, "countries": { "store": false, "type": "string" }, "manufacturer": { "fields": { "name": { "store": false, "type": "string" } }, "type": "document" }, "tags": { "store": false, "type": "string" }, "title": { "store": false, "type": "string" } } }, "storedSource": { "include": [ "dealPrice", "createdOn" ] } }