Melkij

raise notice '%', l_json->>l_key;
всё

melkij=> SELECT * from ts_debug('russian', 'дело сделать кот наконец то');
 alias |    description    |  token  |  dictionaries  |  dictionary  | lexemes 
-------+-------------------+---------+----------------+--------------+---------
 word  | Word, all letters | дело    | {russian_stem} | russian_stem | {дел}
 blank | Space symbols     |         | {}             |              | 
 word  | Word, all letters | сделать | {russian_stem} | russian_stem | {сдела}
 blank | Space symbols     |         | {}             |              | 
 word  | Word, all letters | кот     | {russian_stem} | russian_stem | {кот}
 blank | Space symbols     |         | {}             |              | 
 word  | Word, all letters | наконец | {russian_stem} | russian_stem | {}
 blank | Space symbols     |         | {}             |              | 
 word  | Word, all letters | то      | {russian_stem} | russian_stem | {}
(9 строк)

lexemes text[] — the lexeme(s) produced by the dictionary that recognized the token, or NULL if none did; an empty array ({}) means it was recognized as a stop word

https://www.postgresql.org/docs/current/textsearch...

Там же, далее:

melkij=> SELECT ts_lexize('russian_stem', 'наконец');
 ts_lexize 
-----------
 {}

ts_lexize returns an array of lexemes if the input token is known to the dictionary, or an empty array if the token is known to the dictionary but it is a stop word, or NULL if it is an unknown word.

Используемый словарь намеренно отмечает это слово как бессмысленное слово, не используемое для поиска.

Если вы с таким поведением не согласны, используйте другой словарь или делаете свой: https://www.postgresql.org/docs/current/textsearch...

При отсутствии явных функций форматирования даты в запросе стиль вывода timestamp задаётся настройкой datestyle. Это на выбор несколько предустановленных форматов. Для таймзоны форматирование вида здесь. Стиль USE_XSD_DATES используется в xml и json, но через datestyle его использовать невозможно, а потому минутная часть в выводе будет присутствовать только отличная от нуля.

В целом, форматирование датывремени - это не задача запроса к базе, это задача вывода данных в конечном приложении.

Начну с конца - для индексов это критично разные вещи. Планировщик даже пытаться анализировать не станет, эквивалентные это условия или нет. Если у вас есть индекс по my_column -> 'a', а в запросе вы написали "my_column"['b'] - то этот индекс использоваться не будет.

Касательно самих двух операторов:
-> ровесник jsonb как такового
jsonb[element] - jsonb subscripting на языке документации - штука недавняя, лишь только прошлогодняя из pg14. Пока что нужно иметь в виду если вам может потребоваться более старая версия базы.
По поведению отличий вроде не должно быть никаких. Оба варианта возвращают jsonb, поэтому IRL куда чаще используется ->> возвращающий текст.
На уровне реализации оба приходят к одному и тому же getKeyJsonValueFromContainer. Вы скорее упрётесь в производительность разбора формата самого jsonb, чем заметите какую-то разницу в производительности родного оператора от type subscripting.

• 3 независимых экземпляра postgresql на разных портах через потоковую репликацию. Просто, стабильно, надёжно
  
• какая-то из форм логических репликаций. Приключения по сопровождению за свой счёт. Начать с pub/sub как штатный механизм
  

Весь раздел https://www.postgresql.org/docs/current/internals.html
за исключением разве что System Catalogs

Узел Index Scan в плане запроса - это далеко не одна функция, а целый отдельный src/backend/executor/nodeIndexscan.c
Ну и кучка поддерживающих конструкций, чтобы от этого был толк. Большая кучка конструкций. Очень.

Как функция index scan в postgresql понимает тип индекса?

А ему и не надо.
Если планировщик выбрал index scan - значит этот index access method предоставляет совместимый интерфейс. Далее index scan согласно контракту index access method дёргает методы этого конкретного AM, и уже сам AM решает, где у него что лежит и как доставать требуемые TID по заданным условиям.

и как именно Postgre понимает, какую функцию следует применять

postgresql или postgres. Базы postgre не существует.
А муками выбора о плане запроса страдает планировщик, работающий перед executor'ом. И там настоящая чёрная магия (и костыли)

Добавьте в log_line_prefix как минимум %h, затем ищите на том хосте, кто может пытаться запустить walsender. Это может быть как физическая, так и встроенная логическая репликация.
%u в log_line_prefix покажет каким логином этот процесс авторизовался, может навести на какие-то мысли о том что именно искать.

Эти две команды именно про enum:

ALTER TYPE name ADD VALUE [ IF NOT EXISTS ] new_enum_value [ { BEFORE | AFTER } neighbor_enum_value ]
ALTER TYPE name RENAME VALUE existing_enum_value TO new_enum_value

Вот удаления значения из enum нет.

Команды ADD/DROP/ALTER/RENAME ATTRIBUTE там же - это как раз про композитные типы. Уже используемые менять можно.

Используйте более подробный log_line_prefix. В частности, нужен %h

log_line_prefix = '%m %p %u@%d from %h [vxid:%v txid:%x] [%i] '

Мы такой используем если нет значимых причин для иного.