Melkij

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

Ведь память это же самое дешевое, что можно сделать на кристалле?

Это как раз обычно самое дорогое - самый большой по площади регион. Больше площадь = меньше кристаллов с пластины. Больше площадь кристалла = выше риск получения брака у каждого из кристаллов. Меньше исправных кристаллов = выше стоимость каждого.

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 как штатный механизм
  

mdadm --grow /dev/mdX -n 2

Весь раздел 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 покажет каким логином этот процесс авторизовался, может навести на какие-то мысли о том что именно искать.