Opened 8 years ago
Closed 8 years ago
#27442 closed New feature (wontfix)
count estimation on querysets
Reported by: | Denis Cornehl | Owned by: | Denis Cornehl |
---|---|---|---|
Component: | Database layer (models, ORM) | Version: | 1.10 |
Severity: | Normal | Keywords: | |
Cc: | Triage Stage: | Unreviewed | |
Has patch: | no | Needs documentation: | no |
Needs tests: | no | Patch needs improvement: | no |
Easy pickings: | no | UI/UX: | no |
Description
on bigger tables a normal count()
gets slow quickly, though quite often we only need a rough estimation (for pagination for example, see #26451 ).
I want to add a new estimate_count
method on QuerySets to allow users to access this count estimation.
For Postgres and other databases this is possible by using the query planner statistics to do this estimation.
Change History (4)
comment:1 by , 8 years ago
comment:2 by , 8 years ago
This is especially hard to do as soon as your queryset as any filters applied to it.
comment:3 by , 8 years ago
@Simon thanks for the article, with the method I want to use (explain output based) I don't see any big problem there.
It's an estimation, and will never be exact, and often outdated.
What would be a valid definition for "reliable enough" we could follow here?
Adding this to all backends is definitely quite some work, since all of them have statistics, but I do believe it's not so simple to translate them into this count estimation, as it is for postgres
comment:4 by , 8 years ago
Resolution: | → wontfix |
---|---|
Status: | assigned → closed |
This has already be mentioned in #11287 and it was deemed hard to implement such a function returning reliable results. There's multiple way of achieving this on PostgreSQL alone which makes me feel this is somewhat application specific.
I'm -1 for adding this only for PostgreSQL and -0 if we come up with a reliable method on all backends.