[11.x] Paginator total override #46410
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Resubmission to master of #46336
This allows the user to declare the total number of results a query returns. If the user provides this argument, the
paginate()
method will skip running its query to determine the total row count. to be clear, this does not change the number of actual results available, just how many the paginator thinks exist.Why would we want to set this value when we can use a query to determine it?
Performance.
can be terribly slow on large tables, depending on your database and table engine.
For example, on MySQL with an InnoDB engine, a table with 500,000 rows can take 300ms. Eliminating this query can save a considerable chunk on the entire request time.
You might ask, "why not use the simple paginator or cursor paginator to achieve this?". That would eliminate the extra query, but the downside is you lose the ability to quickly navigate directly to pages.
Users are free to calculate or choose this number any way they like. You could assume your users will never care about more than 100k records back from the most current, and use that if you like. Surprisingly, assuming your have an auto-incremented
id
field and rows are either never deleted or soft-deleted, you can runto retrieve the last ID, and this query is significantly faster.