On Wednesday 09 August 2017 00:40:30 Josh Smeaton wrote: > We use the explain analyze method at work, but I don't think it's an > appropriate thing to include in core. >
Agreed. > I'm not so sure about providing count estimates in core, but I don't fully > grok how the `estimate_above` would work in practise. Would that execute > two queries if the estimate returned a value below the threshold? That's what I had in mind. But two queries do not have to mean two database roundtrips: Since the estimation queries are backend-specific anyway, we might as well implement `table_count(estimate_above)` using blocks of procedural SQL. I am, again, not suggesting a change to count() at the ORM level -- this should be a new API; I *am* suggesting that the admin would use this new API where appropriate (when the admin queryset has no filters or joins which could affect the count). > I think > this could be tackled in a separate patch because it would then feed into > the expansion of the paginator. > Yes, the idea of controlling whether any count is done, while not entirely orthogonal, is certainly of value regardless of this idea, and can (and should) be dealt with separately. Shai.
