[BUG] FT.AGGREGATE performance problem about redisearch

[meiravgri]

Hi @cvija1
Multiple field sorting is indeed not available with ft.search.
The processing pipeline complexity of FT.AGGREGATE can indeed impact query execution duration.
However, without the ability to perform multiple field sorting in FT.SEARCH, it's not possible to fairly compare between FT.SEARCH and FT.AGGREGATE.

To assist you better, please provide more details about your index schema and perhaps an example query. With this information, we can explore alternative approaches to enhance the query performance based on your specific requirements.

[cvija1]

Hi @meiravgri
I have simple index
FT.CREATE vodIndex ON JSON PREFIX 1 content:vod: SCHEMA $.vodContentId AS vodContentId NUMERIC SORTABLE
I try these two commands
FT.SEARCH vodIndex * SORTBY vodContentId limit 0 0 and
FT.AGGREGATE vodIndex * LOAD * SORTBY 1 @vodContentId limit 0 0
It seems similar query but response time for FT.SEARCH is about 60ms but for FT.AGGREGATE is something about 250ms. I have about 12k documents.

[meiravgri]

Hi,
when you run a query withlimit 0 0, all it does is to return the number of results.
This makes the sorter meaningless (since we only count the results and do not sort them).
However, when using FT.AGGREGATE with LOAD before the SORT, you also add the overhead of loading the document from redis keyspace, which is a heavy operation.
try:

1. remove the limit (the default limit is 10 results)
2. moving the LOAD after the sort
   FT.AGGREGATE vodIndex * SORTBY 1 @vodContentId LOAD *

[cvija1]

Hi,
I used these two example queries only for test response time. Query that I use in my application is more complex than these. Because of that, first suggestion is meaningless, but I will try second suggestion and send you results.

[cvija1]

Hi @meiravgri,
putting LOAD after sort resolved my performance problem, but I think that you should mention that in official documentation. Also, it should return error if LOAD is before sort. However, in official documentation for FT.AGGREGATE, LOAD is above SORT.
Thank you

[meiravgri]

As i said, these 2 queries are not equal, therefore, they can't be used to compare these two commands' performance.

LOAD before SORT is a valid use case, where you want to load document values in order to sort by them.