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.