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.


> 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  

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.


Reply via email to