Hi Redis,

Our teams asked earlier about why our FT.SEARCH is slow - queries like this will get slower and slower as the offset grows:

FT.SEARCH idx (@address\.region:{NY}) RETURN 2 B BYTES LIMIT 0 10
FT.SEARCH idx (@address\.region:{NY}) RETURN 2 B BYTES LIMIT 70000 10

We were recommended to use FT.AGGREGATE with the Cursor API for pagination instead for better performance. However, for our use cases like above, we want to get all fields back for each matching result, which FT.SEARCH does by default but FT.AGGREGATE does not. So we wonder what is the FT.AGGREGATE equivalent of our queries?

We checked LOAD *, which appears to load all documents at the first FT.AGGREGATE query, before fetching each page, if I understand correctly? That would be slow if our user only wants the first page right?

We do not want to make all our fields SORTABLE either, since some of them are not sortable.

So in conclusion, can we have the exact behavior of FT.SEARCH but use a cursor for pagination to improve performance?

Hi @cheng

FT.SEARCH gets slower since it has a sorter which keeps OFFSET+LIMIT results in a heap. As the limit grows, this heap works harder and the query gets slower.
FT.AGGREGATE should be significantly faster since you will avoid the sorter altogether (which FT.SEARCH has by default).

FT.AGGREGATE idx (@address\.region:{NY}) LOAD * WITHCURSOR COUNT 10.

Please let us know if this works out for you or if you need further assitance.