Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP

Loading…

Search pager refactoring needed #429

Open
mworrell opened this Issue · 0 comments

1 participant

@mworrell
Owner

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)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.