Вы сделали регистронезависимый JOIN по email как LOWER(u.email) = LOWER(s.email), и запрос стал заметно медленнее. Какое объяснение наиболее вероятно на базовом уровне и что обычно делают в аналитических витринах?

ALOWER делает сравнение «случайным», поэтому результаты плавают; надо заменить на UPPER.
BJOIN всегда медленный, и ускорить его нельзя.
CПроблема в том, что LOWER меняет тип на int; нужно вернуть text через ::text.
DФункция над колонкой усложняет использование индекса/оптимизаций; часто хранят отдельное нормализованное поле (например, email_lower) и соединяют уже по нему.
Правильный ответ. Функции в условии соединения могут делать запрос тяжелее; нормализацию часто выносят в отдельное поле.

Разбор

Нормализовать строки в запросе удобно, но это добавляет вычисления и может ухудшать использование оптимизаций при соединениях. Типичный практичный подход — хранить нормализованное значение (например, email в нижнем регистре) в витрине или материализованном слое и использовать его в JOIN и фильтрах.

Проверь себя · 1/3разбор после ответа
В таблице products категория хранится как Books, books, BOOKS. Вы хотите отфильтровать все варианты категории «books» в одном запросе. Какое условие в WHERE наиболее надежно?
Тренировать SQL в Telegram

Ещё вопросы по теме «Строки и приведение типов»