+1 from me, I've spent long enough on those COUNT(*) queries at work.
Is it worth putting this logic in Paginator so applications can reuse it?
On 7 August 2017 at 07:45, Josh Smeaton wrote:
> The admin list page performs a count(*) (twice!) when viewing the list
> page of a model. One of these
Is there any way to propose this optimization to be considered? I have
never posted code to the Django community.
El divendres, 4 agost de 2017 15:20:55 UTC+2, Collin Anderson va escriure:
>
> I can confirm it's slightly faster in my case (maybe 20-50ms for 58 rows,
> 3 inputs per row).
>
> I ca
I've made a ticket here: https://code.djangoproject.com/ticket/28472#ticket
. You can follow https://docs.djangoproject.com/en/dev/intro/contributing/
to make a Pull Request on GitHub against this ticket 👌
On 7 August 2017 at 09:19, ecas wrote:
> Is there any way to propose this optimization to
Yes, the ability to disable all COUNT(*) is important (at least on Postgres).
--
Aymeric.
> On 7 Aug 2017, at 09:02, Adam Johnson wrote:
>
> +1 from me, I've spent long enough on those COUNT(*) queries at work.
>
> Is it worth putting this logic in Paginator so applications can reuse it?
>
This is a great idea. A related issue I've come across with the paginator
is not being able to pass an explicit count into it.
If you have a query set with expensive annotations that don't effect the
count in any way it's very wasteful to include them in the count SQL
statement (on top of general
Declaring a cursor WITH HOLD means it can be used outside transactions, but
it seems like the server-side cursors are already set up WITH HOLD when
autocommit is on:
https://github.com/django/django/blob/master/django/db/backends/postgresql/base.py#L212
So I'm guessing maybe you've disabled tra
I think I prefer documenting Berker's suggestion rather than adding more
classes to Django, unless perhaps, they add some additional functionality
as HttpResponseNoContent does.
Did you intend to have response subclasses for all 57 values of
http.HTTPStatus?
On Sunday, August 6, 2017 at 4:17:2
>
> Did you intend to have response subclasses for all 57 values of
> http.HTTPStatus?
I hadn't entirely thought it through before implementing :) I agree it's
too much, and many are highly unlikely for Django applications to respond
with, e.g. 203 Non-Authoritative Information.
I'll document th
On PG we can and should do much better -- there is a way to get a very fast,
though not accurate, count of records in a table:
https://wiki.postgresql.org/wiki/Count_estimate
I think we should expose an API along the lines of
queryset.table_count(estimate_above=2000)
which act
Mysql, Oracle and Postgres expose estimated rows in a pretty similar manner
(selecting the table name from a database-specific table). Perhaps a more
generic 'estimate_table_rows' function could be added for all backends? I
guess for sqlite it would have to use an actual count() as a fallback. This
With a little more than a month to go until the Django 2.0 alpha (targeted
for September 18), I'd like to make a final decision about whether or not
to keep Python 3.4 support for Django 2.0. Jenkins is currently running the
tests on pull requests with Python 3.4 and 3.6. I've seen a few times w
11 matches
Mail list logo
