RediSearch SORTBY performance

Hi everyone, I have a question about the cost related to the use of SORTBY in FT.SEARCH.
The documentation states: “In the current implementation, when declaring a sortable field, its content gets copied into a special location in the index, for fast access on sorting”.
I would like to know if “fast access” means as fast as the default ordering based on document ids. In other words: is there any performance decrease due to the use of the SORTBY clause on a sortable field in an FT.SEARCH?

Thank you for your help!

Hey @farcitoast, on ft.search there is always a sorting phase, if no sortby is specify, RediSearch sorts by the document score. So if the field you sort by is sortable (i.e we can access it fast) there should be no real impact on the peformance compare to not specify sortby.

On FT.AGGREGATE its a different story, there is no default sorting on FT.AGGREGATR so any sortby phase will slow it down (compare to not specify sortby).

Thank you for your answer, much appreciated!

1 Like