Может, Postgres его не видит?

Не обязательно. Иногда он просто посчитал, что через индекс будет дольше.

Представим таблицу на 200+ млн строк и индекс по status. Запрос выбирает заказы со статусом completed, а таких записей 80% таблицы. Ради чего читать индекс, переходить по нему к куче строк, а потом почти всё равно вычитывать таблицу? Последовательное чтение здесь вполне может оказаться дешевле.

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

Когда запрос тормозит, я бы начал с простого: EXPLAIN (ANALYZE, BUFFERS) SELECT * FROM orders WHERE status = 'completed';

Смотреть только на Seq Scan смысла мало. Важнее, сколько строк PostgreSQL ожидал получить, сколько получил на самом деле и сколько буферов пришлось прочитать. Вот здесь часто и становится понятно, куда копать.

Если оценки сильно расходятся с реальностью, проверь статистику для начала можно выполнить ANALYZE. Если не помогло, а данные распределены неравномерно или условия зависят друг от друга, придётся разбираться глубже: настраивать statistics target, смотреть в сторону CREATE STATISTICS. VACUUM тоже нужен для нормального обслуживания таблиц, но сам по себе проблему плохих оценок не решает.

И не надо сразу пытаться победить Seq Scan через enable_seqscan=off. Для диагностики сравнить планы можно, но оставлять такую настройку как способ лечения плохая идея.