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.