[ledoublegui]

Hi dawnerd! Sorry to hear that, do you have the issue link so that we can take a look at it?

Based on the informations I can read here, I think it comes from the fact that the engine is not able to give an exhaustive finite number of records matching the query for reasons of response time. A finite pagination style (with number of pages) on the client-side is for now a pure work-around.

From what I understand, some of our users try to use MeiliSearch as a primary datastore or expect a classic finite pagination coming from a SQL database env, when we are here to solve search relevancy problems.

Ideally the search results should be relevant enough so that end-users don't have to click on another page selector button, that's why we advocate to integrate a pagination without number selection. Infinite scroll style or prev/next.

Happy to discuss this further with more context!

Thank you for your feedback :)

[dawnerd]

Yeah having a cap on the number of results is fine. Problem is when it queries for every item at once. I’ve tested on large datasets and my patched version of instantsearch has no performance problems over 100 pages w/30 items per page. Every time you clicked next page it would request maxPages * perPage but start from index 0.

Im not using as a primary data store.

https://github.com/meilisearch/instant-meilisearch/issues/18

[ledoublegui]

Thanks for your answer dawnerd. I will take a look at it with fresh eyes, we may have missed something :)