#14131: The pagination module should have some limit, or a warning should be
given
in the documentation
-----------------------------------+----------------------------------------
Reporter: mlissner | Owner: nobody
Status: new | Milestone:
Component: Contrib apps | Version: SVN
Resolution: | Keywords:
Stage: Accepted | Has_patch: 0
Needs_docs: 0 | Needs_tests: 0
Needs_better_patch: 0 |
-----------------------------------+----------------------------------------
Changes (by PaulM):
* needs_better_patch: => 0
* stage: Unreviewed => Accepted
* needs_tests: => 0
* needs_docs: => 0
Comment:
I agree that this should be documented as a potential gotcha.
LIMIT/OFFSET is slow for the reasons you mentioned.
There are a number of ways around this problem. One approach is to index a
table and use WHERE/LIMIT rather than LIMIT/OFFSET. I'm not sure where in
Django this sort of optimization belongs. On the one hand, it's a problem
shared by all queryset slicing operations that produce a LIMIT/OFFSET
statement. On the other, it requires specific knowledge about the contents
of the table (and an index), so it might be easier to pass the clue in to
a custom bit here in Pagination. Or possibly I'm completely off base here.
More discussion of the same issue here:
http://stackoverflow.com/questions/1243952/how-can-i-speed-up-a-mysql-
query-with-a-large-offset-in-the-limit-clause
and slides 12 to 14 dicuss the WHERE/LIMIT approach here:
http://www.slideshare.net/Eweaver/efficient-pagination-using-mysql
--
Ticket URL: <http://code.djangoproject.com/ticket/14131#comment:1>
Django <http://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
--
You received this message because you are subscribed to the Google Groups
"Django updates" group.
To post to this group, send email to django-upda...@googlegroups.com.
To unsubscribe from this group, send email to
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-updates?hl=en.
