Shavadrius
1. На бэкэнде не получится, потому что это (цитирую) "подзапрос вида (внутри Exists())", а используется он внутри WHERE. Для 1000к записей может и проканало бы, но не для 100кк.
2. С одной стороны да, но тогда индекс тоже надо сделать соответствующий. У меня получилось добиться parralel index scan, что думаю быстрее (на практике не заметил разницы, видимо слово попадалось в одном индексе).
3. Можно. Но зачем? У меня используется общая логика по поиску, которая требовала просто индексов.
Вообще я думаю там ещё кое-что оптимизировать, но именно эти условия формирует ORM в той части кода, которую не хочется менять. Вопрос был в том, как правильно именно джанговские индексы сформулировать, чтоб работали с LIKE и UPPER.
Alexej Belkin, вы сами разве не видите, что у вас заметно отличается PATH?
Уверен, что если у вас будет `/USER_FOLDER/.local/bin` в `PATH` идти впереди, то всё заработает. Но вообще всё проще: поставьте зависимости в `myprojectenv` такие же как у вас в `$HOME/.local`.
Можете сравнить окружения по версиям: `pip freeze` и `/home/USER_FOLDER/APP_FOLDER/myprojectenv/bin/pip freeze` - версии будут отличаться.
Alexej Belkin, вопрос того, в каком окружении вы находитесь. Если вы в виртуальном окружении, то у вас много что совершенно иначе работает. Поэтому вам и рекомендовали полный путь указывать. Вы подробнее про своё окружение расскажите, все переменные окружения в скрипте и за его пределами покажите (всё что парольное, не забудьте удалить), как и где запускаете и т.п. А то гадания на кофейной гуще.
Посмотрите какие os.environ у вас. Попробуйте передать их в run через аргумент env (это тоже словарь).
AGPLv3 (ниже не можем, потому что зависимости требуют)
Я так и написал. Просто вопрос в том, что мы в самом приложении используем зависимости с GPLv3, а в модуле расширения перегружаем часть нашего же приложения. В самих перегрузках и коде перегрузки не используется ничего, кроме своего или с менее строгими лицензиями.
1. На бэкэнде не получится, потому что это (цитирую) "подзапрос вида (внутри Exists())", а используется он внутри WHERE. Для 1000к записей может и проканало бы, но не для 100кк.
2. С одной стороны да, но тогда индекс тоже надо сделать соответствующий. У меня получилось добиться parralel index scan, что думаю быстрее (на практике не заметил разницы, видимо слово попадалось в одном индексе).
3. Можно. Но зачем? У меня используется общая логика по поиску, которая требовала просто индексов.
Вообще я думаю там ещё кое-что оптимизировать, но именно эти условия формирует ORM в той части кода, которую не хочется менять. Вопрос был в том, как правильно именно джанговские индексы сформулировать, чтоб работали с LIKE и UPPER.