FYI Django-MySQL supplies an approx_count() method:
. It only works on QuerySets without filters. From what I understand it's
possible to get an estimate for filtered queries in MySQL in *some*
circumstances, but you need to be filtering on only one index and not
involve any joins.

I'm in favour of adding this (by whatever name) to core.

On 8 August 2017 at 23:12, Shai Berger <> wrote:

> 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
> 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.


You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
To post to this group, send email to
Visit this group at
To view this discussion on the web visit
For more options, visit

Reply via email to