| | 17 | |
| | 18 | |
| | 19 | Additionally, if the above is accepted, then the only use of full_result_count is on the search page, which opens up another opportunity to optimize. As discussed further in #8408, there are two different SELECT COUNT(*) calls. One is for the paginator, which operates on the filtered results and one is for full_result_count which is unfiltered. The latter is only used once (if the above suggestion is adopted), in contrib/admin/templates/admin/search_form.html. |
| | 20 | |
| | 21 | So we could skip calculating full_result_count if there is no search being done. Note that this is subtly different than if there are no filters; see #22810 for why that is an issue. |
| | 22 | |
| | 23 | Alternatively, if you want to be safe and not make assumptions about what people might be doing with full_result_count, this also works: full_result_count = lazy(self.root_queryset.count()). Then if it is never evaluated, the query never runs. I've tested both approaches. |