Arbitrary limits on `sort_by` and `per_page`

[JustArchi]

Description

Hey, first of all thank you a lot for creating this awesome software.

We're currently trying to adopt your software for our internal solutions, and we've stumbled upon two rather annoying limits that seem arbitrary. In particular, that is limiting sort_by clause to only 3 fields, and per_page to 250. This currently doesn't meet our requirements, as we need to sort/include more than allowed number.

Steps to reproduce

Well, simply specify per_page=300 or more than 3 fields in sort_by.

Expected Behavior

I'd expect those limits to be configurable in the provided ini config. It doesn't seem rational making it hardcoded at compilation time. I agree that some limits have to be put in place, but it should be up to the system administrator how severe those are.

Actual Behavior

Error code 400 when out of the hardcoded range.

Metadata

Typsense Version: 0.22.2

OS: Debian Stable

---

Thank you in advance for your time in regards to this issue.

[kishorenc]

@JustArchi

Both limits are unfortunately part of the trade-offs that we had to make while designing Typesense. As a search engine Typesense is optimized to find the most relevant documents fast from a large set of documents. Part of the speed comes from the decision to restrict the possible top results to the top few hundred (we're able to make some optimizations). Even if we removed the 250 limit, it will become really slow to fetch documents past that, when you have millions of records.

In the same way, restricting possible number of sort fields to 3 allows us to implement optimizations that help in speeding up search. While designing software, we always have to indulge in trade-offs because there is almost always no perfect solution that caters to all use cases. I'm sorry that these limitations are a blocker for your use case, but we can't relax these requirements given that they are a core part of the design.

[JustArchi]

Thanks for very swift response @kishorenc.

That's understandable, what if somebody is willing to give up performance over those features? A custom solution that will trigger typesense several times in a row just to buffer the per_page results to bigger number will still be much worse than typesense returning all of them at once. Likewise with sorting, I'd need to code my own stuff just to add another pass over the results, which will have awful performance entirely nullifying the planned use case of using typesense to begin with.

Well, the decision is up to you, if you consider this as hard design decision that you're not willing to change, I'll respect that, but I'd welcome worse performance with satisfying use cases rather than being forced to consider other solutions just because of those limits - they don't seem like some critical values impossible to change. The decision is yours, but maybe it's worth reconsideration.

[kishorenc]

While we could perhaps allow a larger per_page value (with the associated performance and memory impact), the fixed number of sort fields is tightly integrated into the overall design, so it's certainly not possible to change that, unfortunately. If the sort order is pre-computable, you could perhaps consider combining several fields and indexing as a single field value.

[JustArchi]

Well, I don't want to pressure you further on this matter, thank you for your time answering my concerns, I'll see what I can do with it 🙂

[boldtrn]

I just wanted to circle back to the 250 limit. Would it be possible to add some sort of config option to remove that limit by accepting slower responses?

[kishorenc]

Please see my comment from yesterday on a related issue on how you can use multi search as a work around: #672 (comment)

[mahmudtopu3]

I am having a similar issue because it returns 250 max, Our django app has it's own pagination system, so combing both is tough,
Getting the primary keys and they running "IN" queries to get the queryset seems to work but don't know the better way of doing it,.
If I only use typesense without the queryset return from django, then it will be a totally separate api. (listview will not connect to the DB)
Any suggestions?