Кто-нибудь юзал zalando postgres-operator ui?

с конфигмапом логирование работало, а вот когда подключил crd логи перестали быть доступны

Возможно поможет триграмный поиск

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

1. Если регулярка не с начала строки, то единственное что может её ускорить, насколько я знаю, триграммный индекс из расширения pg_trgm USING GIN(column gin_trgm_ops). Можно попробовать и GIST.
Без нескольких фиксированных символов внутри регулярки он бесполезен или даже вреден. На моих данных
Примеры на таблице в 2 млн записей:
'^\d{2}:\d{2}$' - Index Scan, 3,3 секунды, 60 строк
'^[a-z]$' - Index Scan, 0,003 секунды, 0 строк
'[a-z]' - Index Scan, 3 секунды, 0 строк
'^\d{2}:\d{2}:\d{7}$' и '^\d{2}:\d{2}:\d+$' - Seq scan, 2,5 / 1,2 секунды, 18336
'^\d{2}:\d{2}:000\d{4}$' - Index Scan, 1,3 секунды, 776 строк
'^\d{2}\:\d{2}\:0001\d{3}$' -  Index Scan, 0,7 секунды, 40 строк
'^\d{2}\:\d{2}\:00010\d{2}$' -  Index Scan, 0,25 секунды, 40 строк
2. Если у вас не совсем полноразмерная регулярка, то вам может подойти полнотекстовый поиск. Для поиска "лексем начинающихся с этих букв" используйте to_tsquery('набор правил', 'слово:*'). Но там есть свои заморочки, в частности стандартный словарь стоп-слов.

Если вам нужно один раз пройтись и разметить - можно выгрузить данные, разметить и потом загрузить.

Шаблоны могут менятся и новые данные в таблицу попадают каждый час, на ее основе строится дашборд в Power BI

Новые данные - вы их можете эффективно выудить, не приводя к full table scan?

думаю, что нет

Новый шаблон - просмотр всей таблицы. Здесь индекс может помочь, а дальше уже надо смотреть.

Не хотите пометить их прямо на входе?

не думал об этом, я в первую очередь подумал об индексах и нагуглил про gin

На уровне приложения, в зависимости от попадания шаблона менять значение целочисленного индексируемого поля. По нему и искать

Хм... триггер на вставку?

Не совсем. Для примера пытаюсь в несколько потоков в одной транзакции сделать select for update и если нет строки, то вставить. Ожидал, что будет работать блокировка, но по факту проскакивают попытки вставить одно и то же в разных транзакциях.

А unique constraint над суррогатным ключем или над чем-то существенным?

В синтетическом примере на все поля, кроме ключа.

Я ожидал, что блокировка предотвратит состояние гонок. Но похоже это так не работает.

Невозможно заблокировать то чего не существует

Можете попробовать уровень изоляции serializable поставить, но  его нужно будет включать вообще для всех транзакции.
Тогда у вас эта ошибка скорей всего уйдёт и будет другая ошибка - ошибка сериализации данных.

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