Melkij

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

Эти две команды именно про 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 там же - это как раз про композитные типы. Уже используемые менять можно.

и деморализующий ответ от postgresql DBA

Вливаюсь в администрирование(в postgres на данном этапе)

То есть опыта системного администрирования нет?
А сколько лет опыта в разработке?
Если оба ноль - выберите себе цель более реальную.
Я не знаю ни одного DBA, у которого за плечами не было бы заметного опыта или системного администрирования или в разработке (у меня вот до сих пор больше лет опыта собирания граблей в разработке, чем опыта DBA).
И, что для вас куда хуже, не имею представлений для какой работы может понадобится DBA без существенного багажа знаний, который подразумевает эта работа. Открыл вот HH и почему-то не могу найти вообще ни одной вакансии junior DBA. Да что говорить - полный результат поиска вакансий postgresql DBA укладывается в одну страницу.

Таковы реалии DBA. Обычно будущий DBA выглядит или как опытный сисадмин, вникающий в работу SQL или как разработчик, к которому приходят коллеги с вопросами про работу СУБД.

примеры проектов, которые не оторваны от реальности.

1. доклад на конференции
   
2. тут бы я написал sql ru, но его больше нет. Попробуйте отвечать на q&a хабра или ru.so. По моим наблюдениям они бесполезны и активность тут никого не интересует, в отличии от sql ru. Но зато некоторого опыта набраться можно, попутно потренировав ключевой навык любого IT - поиск информации
   
3. посты на хабре
   
4. вменяемый bug report (в самом postgresql или широко известных штуках рядом), впоследствии исправленный
   

Что DBA может показать на гитхабе? Не знаю, postgres/postgres коммит с упоминанием своего имени, разве что.
Дамп какой-то базы? Если только с детальным описанием предметной области и задач. А читать это всё хоть кто-то будет?