2016-10-04 14 views
3

Известно, что представления списков администраторов Django становятся довольно медленными, когда в таблицах базы данных есть много строк. Это связано с тем, что по умолчанию для почтового индекса Django используется (медленный) запрос PostgreSQL COUNT.Как ускорить страницы администрирования Django с оценками count PostgreSQL?

Как оценка будет хорошо для нас, и это гораздо быстрее, например: SELECT reltuples FROM pg_class WHERE relname = "my_table_name"

Существует фрагмент кода доступны, чтобы исправить эту проблему, но пока непонятно мне, как на самом деле использовать его: https://djangosnippets.org/snippets/2593/

Кроме того, фрагмент не должен работать с отфильтрованными результатами. Это потому, что подсчет оценки, как показано выше, здесь не работает. Есть ли другой способ ускорить просмотренные просмотры списков в страницах администрирования Django?

ответ

1

Вы можете использовать его переопределение класс ModelAdmin.paginator

постраничной навигации, который будет использоваться для нумерации страниц. По умолчанию используется django.core.paginator.Paginator. Если пользовательский класс paginator не имеет такого же интерфейса конструктора, как django.core.paginator.Paginator, вам также необходимо предоставить реализацию для ModelAdmin.get_paginator().

class MyModelAdmin(admin.ModelAdmin): 
    paginator = CachingPaginator 

Бонус особенность: я улучшил на этом фрагменте, чтобы создать одну, которая работает с и без фильтров: https://gist.github.com/e4c5/6852723 он получает отсчет от rel_tuples, когда это возможно, но когда фильтр используется счетчик будет сохранен в кэше ,

Update 1:
Проблемы с оригинальным сниппета обозначаемым в вашем ответе из-за это изменение, объявленным в примечаниях 1.6 релиза: https://docs.djangoproject.com/en/1.10/releases/1.6/#get-query-set-and-similar-methods-renamed-to-get-queryset

Это тривиальное исправление.

обновление 2
Мое усовершенствование оригинального фрагмента кода было сделано то, что некоторые устаревшие в _count СОБСТВЕННОСТИ переименовывается сосчитать, а также его украшают как cached_property

+0

Я вижу, как использовать его; но ни один скрипт не работает с Django 1.10. Ваш ответ возвращает ошибку «Объект CachingPaginator не имеет атрибута« _count »- исходный скрипт возвращает объект« LargeTableChangeList »не имеет атрибута« query_set »- любые идеи? –

+0

Спасибо за обновление. К сожалению, все еще не работает. Переименован '_count' в' count'. Теперь я получаю ошибку «превышение максимальной глубины рекурсии при вызове объекта Python» для строки 'if self.count is None:' - как в вашем, так и в другом фрагменте. –

+0

Я думаю, что мы сейчас далеки от первоначальной сферы вопроса, а именно о том, как использовать этот фрагмент, и мы считаем, что это более чем адекватно. Пожалуйста, задайте новый вопрос, говорящий, что вы используете этот фрагмент (включая код в самом вопросе) вместе с ошибкой – e4c5

0

Существует возможность выбрать желаемый поведение, так как Django 1.8: https://docs.djangoproject.com/en/1.8/ref/contrib/admin/#django.contrib.admin.ModelAdmin.show_full_result_count

Пример:

class MyModelAdmin(admin.ModelAdmin): 
    show_full_result_count = False 
+0

Ссылка на решение приветствуется, но, пожалуйста, убедитесь, что ваш ответ полезен без него: [добавить контекст вокруг ссылки] (// meta.stackexchange.com/a/8259), чтобы у ваших коллег было некоторое представление о том, что это такое и почему он там, затем укажите наиболее релевантную часть страницы, на которую вы ссылаетесь, в случае недоступности целевой страницы. [Ответы, которые немного больше, чем ссылка, могут быть удалены.] (// stackoverflow.com/help/deleted-answers) –