Как использовать функциональные индексы Postgres из Django?

Question

[un1t]

В постгресе есть функциональные индексы

Просмотроел доку:
https://docs.djangoproject.com/es/1.10/ref/contrib...

Вроде ничего такого нет.

Может какое-то приложение есть для этого?
Сейчас в голову приходит только написать сырой запрос в миграции, но это какой-то страшный костыль.

Answer 1

[Roman K]

У джанги нет возможности:
Указывать тип индекса (HASH, BTREE, BRIN, GIN, GIST). Только BTREE.
Создавать функциональные индексы
Создавать частичные индексы

Только костылить чистым SQL в миграциях.

Answer 2

[Артём Клименко]

пока только так, в 1,11 будут первые подвижки в эту сторону class based indexes.

Comments

[un1t]

Это конечно круто, но только релиз в следующем году( К релизу думаю у Постгреса и другие индексы появятся.

Answer 3

[sim3x]

Лучше сделать шаг назад и подумать зачем оно тебе нужно и как написать нагрузочный тест, чтоб понять ты сделал, то что нужно или угробил все

Если принимать решение коллегиально, то я за прописывание sql в миграции

Comments

[un1t]

Да мне нужно просто select .. where name like 'aaa' регистронезависимо.

[sim3x]

un1t: тогда не морочь нам голову и
table.objects.filter(string__icontains='pattern')

[un1t]

sim3x: icontains я бы сказал что использовать можно разве что для отладки, т.к. он не может использовать индексы совсем . В данном случаем мне нужно по полному совпадению, а не частичному, это скорее iexact. Он преобразуется в SQL вида WHERE UPPER(name) LIKE UPPER('"aaa"). А это выражение в постгресе не использует индекс по строке. Но тут может помощь функциональный индекс CREATE INDEX upper_name_idx ON test1 (upper(name));

[sim3x]

un1t: ну вот потому и стоит сделать тест производительности на твоем массиве
Чтоб не заниматься преждевременной оптимизацией

Так-то лучше вообще настроить sphinx search or postgres full text search

[Артём Клименко]

un1t:
для postgres использую такое и индекс в базе

class PgILike(IContains):
    """
    Кастомный field lookups на замену icontains в postgresql
    title__icontains='zk45'
    UPPER("bgbilling_contracts"."title"::text) LIKE UPPER('%zk45%')
    что требует либо построения индексов на upper что не есть хорошо
    title__ilike='zk45'
    "bgbilling_contracts"."title" ILIKE '%zk45%'
    С построенным gist индексом представляет гораздо более интересное решение
    """
    lookup_name = 'ilike'

    def as_postgresql(self, compiler, connection):
        lhs, lhs_params = self.process_lhs(compiler, connection)
        rhs, rhs_params = self.process_rhs(compiler, connection)
        params = lhs_params + rhs_params
        return '%s ILIKE %s' % (lhs, rhs), params

models.CharField.register_lookup(PgILike)
models.TextField.register_lookup(PgILike)

[un1t]

Артём Клименко: дак в джанге наоборот от этого ушли, т.к. ILIKE не может использовать индексы. https://code.djangoproject.com/ticket/3575

[Артём Клименко]

un1t: какие именно индексы? Btree таки да не сможет.
Ставим вот это расширение https://postgrespro.ru/docs/postgrespro/9.5/pgtrgm
>Начиная с PostgreSQL 9.1, эти типы индексов также поддерживают поиск с операторами LIKE и ILIKE, например:

Да наверно стоило это упомянуть сразу, но как-то вылетело из головы. Работает отлично.

[Roman K]

Артём Клименко: Стоит также упомянуть, что это "работает отлично" на небольших объёмах данных. После миллиона уже начинает плыть. На 10 миллионах записей ~ 7 секунд выполняется такой запрос.

[sim3x]

Roman Kitaev: пока мы тут в неведении об обьемах и железе un1t

[un1t]

Артём Клименко: Спасибо за ссылку, может в будущем пригодится. Но в данном случае это кажется избыточным.

Answer 4

[xSkyFoXx]

Это не костыль, а вполне адекватное решение.
Оптимизация запросов и индексы - это сторона базы данных.
Совершенно нормально пойти и создать индексы для таблицы/столбцов, которые ваше приложение использует больше всего. Собственно, по этому такая профессия, как администратор баз данных, живёт и процветает.

Comments

[un1t]

Вопрос не в том нужно ли создавать индекс, а в том на каком уровне это должно происходить. При чему тат админ БД, вообще не понятно, он же миграции в приложения писать не полезет. К тому же про админов исключительно БД я не слышал. Есть админы эксплуатации, они за много что отвечают, но точно не за индексы в таблицах и есть DBA, не уверен что они пишут приложения.

[sim3x]

un1t: DBA - называется профессия
Они проектируют БД, пишут миграции, пишут процедуры и вообще кодят внутри СУБД

Обычно водятся в глубоком интепрайзе

[un1t]

sim3x: а ну ясно, я почему-то думал что А расшифровывается как архитектор)

[sim3x]

un1t: https://en.wikipedia.org/wiki/Database_administrator

Не, тайтл архитектор используется как добавка к тайтлу senior / TL - те вместо того чтоб дать прибавку $500 к зп, тебе дают тайтл и 200