Workaround for inverting sort order without a new index?

My team may soon be required to return search results for a large index of products ranked by price ascending or descending. The documentation is very clear that every sort order requires its own replica index, but we don’t have the capacity without purchasing an additional cluster.

I have two questions:

  1. Why can’t Algolia support inverting sort orders on the same index? I understand why supporting multiple different sort orders would not be compatible with your algorithm, but inverting seems so simple to implement.

  2. We are considering implementing an inverse sort by running a dummy query to get the number of hits, then requesting the pages from last to first. Is there a cleaner way to implement this at query time via the search API?

Hi @rebecca, We are all about keeping your search as fast as possible and as responsive as possible. Any processing on ordering the index, such as sort, needs to happen at index time instead of at search time. This is the reason for keeping each sort order in a separate index.

I’m not sure if I understand your solution to request the pages from last to first. For this to actually order the records in reverse order, you would need to only retrieve 1 hit per page.

You could get your entire list of search results and then manipulate those results to sort them in reverse order. This will be much slower than having a replica index that is already sorted in the reverse order.

So our solution would to pull the pages in reverse order and then reverse the order of the documents on each page before rendering.

What I don’t understand is why we can’t send a query requesting results in inverse order. It’s not a matter of requiring a different sort to happen at index time, it’s a matter of iterating over the results to return in the opposite order. Whether you iterate over a list starting at the first element or the last should not make a difference in performance.

Anyway, it would be really great feature if we could get the data in inverse order as part of the query and avoid the additional processing on the client side, but it seems pretty clear that is not supported right now and we can make do.

Hi Rebecca,
Thanks for your feedback. Just to make sure we’re understanding correctly would the inverse order take into account all of the textual ranking criteria? Aka, you would want the results sorted from least textually relevant / lowest custom ranking? I would love to understand the use case a bit better to make sure we are offering the most relevant solutions / recording the feedback accurately. Thanks!

Oh, that’s an interesting question. In this use case, we’d be sorting by attribute, so textual ranking would only be used as a tie-breaker. It would be ideal to have the tie-breakers still work in the standard order with most relevant on top, but I’m guessing that would not work well with your architecture.

For our use case, I believe that having the least-relevant items on top would be acceptable. Most items that have identical prices in our dataset seem to be related variants of each other that would likely have the same relevance scores as well.

I do understand how it could be awkward for Algolia to expose a feature with such counterintuitive behavior though. And I really appreciate you following up!