Search pager refactoring needed

[mworrell]

Currently we still use a hack to calculate the number of search results. This was placed somewhere in 2009 when we had to release.

We need to add a real way to support the pager, especially with our growing databases.

Just calculating the exact number of results is not doable when you have a lot of results and want to stay fast.

Though here is a solution mentioned (in the comments):

http://gurjeet-tech.blogspot.nl/2011/02/pagination-of-results-in-postgres.html

I propose a strategy where we don't know the number of results, but do know if there are more than the ones we fetched.

Proposal:

• Select the page we want using limit/offset

• Add some extra pages to the limit

• Check how many results we got back:

  • If we got the limit results, unset as is_complete flag
  • If we got less, set the is_complete flag

  In both cases recalculate the number of expected pages.

The pager would then look something like:

[1] [2] [3] ... [more]

Please some feedback.

We could use the exact calculation method if the is_exact_page_count flag is set as an argument to the query (like the page and page length args)

[ArthurClemens]

@mworrell Is this still relevant?

[ddeboer]

See also #599 and #1025.