Из top 15 найденных в DDL ворнингов, 13 касаются индексов. 5 из них рапортуют о различных пересечениях индексов - функциональных с обычными, частичных с функциональными и тд. Еще пять - о различных способах слишком большого покрытия таблиц индексами.
Еще парочка касается индексов и boolean полей.
Первое: не делать индексы только по булевым полям. В большинстве случаев такие индексы не будут использованы, т.к. по цене они будут дороже, чем seq scan.
Второе: не делать сравнение на равенство c булевыми константами (= TRUE). В pg есть две разные конструкции сравнения для булевого типа: = TRUE и IS TRUE. Рекомендуется везде использовать булево поле без сравнений вообще, чтобы не думалось.
Есть индексы на колонки без ограничений размерности. Например, типов TEXT и JSON(B) никак не ограничены. Это может привести к тому, что данные невозможно будет вставить с ошибкой "Values larger than 1/3 of a buffer page cannot be indexed.". Т.е. нужно либо ограничить размер колонки, чтобы он не превышал 1/3 от 8 кб (по умолчанию), либо нужно делать функциональные индексы на хеш значений из этой колонки.
Далее следует одна из совершенно базовых ошибок - сравнение с NULL.
CREATE INDEX ON ... (group_id, title) WHERE (project_id = NULL::integer);
Подразумевается, что он должен ускорить запросы вида
WHERE group_id = 1 AND project_id = NULL
Так вот, сам этот запрос не имеет физического смысла, т.к. project_id = NULL всегда вернет NULL. А TRUE AND NULL постгрес упростит до FALSE.
Т.е. этот индекс никогда не будет использован.
И завершает хит-парад ряд довольно популярных архитектурных ошибок.
Значение по умолчанию без ограничения NOT NULL. В большинстве случаев, если задано значение по умолчанию, разработчик не хочет чтобы оно было NULLом. Иначе зачем значение по умолчанию? :) Но если нет соответствующего констрейнта, то рассчитывать на это уже нельзя. А значит рано или поздно, NULL там окажется и сломает все, что можно сломать.
Причем часть разработчиков Gitlab это учитывает, а часть нет. В итоге схема напоминает письмо родителям дяди Федора из Простоквашино - рядом соседствуют поля с констрейнтами и без них.
Так же присутствуют поля с именем uuid, но типом VARCHAR, массивы идентификаторов, которые не проверяются на консистентность с таблицами, на которые они должны ссылаться и прочее и прочее...
Все сказанное выше, говорит, что архитектуру приложения стоит хорошенько переосмыслить, т.к. видно, что проблемы с тормозящими запросами пытаются решить созданием еще одного индекса, заточенного под конкретный запрос. Большое количество индексов снижает скорость вставки и обновления. Кроме того, как можно заметить, некоторые индексы никогда не будут использованы, а часть из них вообще может привезти к ошибкам в операциях вставки и обновления.