Melkij

Обратите внимание, "получить записи яляющиеся вершинами" и "все записи без родителей" - это разные задачи.

where nlevel(ltree) = 1 -- все записи состоящие из одного уровня.

Записи без родителей - это когда у вас есть ltree "Top.Science.Space.Astronomy", но нет записи "Top.Science.Space"

приведение массива record к массиву композитного типа позиционное, а не символьное. Поменяйте в

SELECT DISTINCT ON (asin) asin, price, reviews, raing

порядок полей на совпадающий с таковым в таблице.

убрали бы лишние подзапросы, что ли.

(SELECT array_agg(j) FROM (SELECT DISTINCT ON (j.asin) j FROM jsonb_populate_recordset(NULL::t_best_asin_ranking_2, '[{
"asin":"B06XH9FNH1",                                                                                                  
"price": 1.5,                                                                                                   
"rating": 1.5,
"reviews": 1
}]') j ORDER BY j.asin) r);

вот так хотя бы.

В настоящее время (pg15) уникальное ограничение может быть только btree индексом.
Следовательно, общее для btree правило префиксного поиска. btree(a,b,c) может так же эффективно использоваться для поиска по префиксу - where a = ? или where a = ? and b = ? - но не может эффективно использоваться для where b = ? или where c = ?

не надо пытаться запутывать планировщик странными условиями, у него своей работы хватает. https://use-the-index-luke.com/sql/where-clause/ob...
Нужно условие в запросе? Добавьте это условие в текст запроса. Не нужно условие? Не добавляйте его в текст запроса.

Уточните в документации к своей библиотеке доступа к базе, как для неё правильно передавать переменное число параметров в параметризованный запрос (prepared statement), подобно эталонному PQexecParams.

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