Melkij

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=...

это пожалуй основная причина и есть. Если вы уведёте систему в сон (hibernate), а затем загрузитесь в другой linux использующий тот же самый swap - вы наверняка потеряете состояние и данные из hibernate режима.
Если вы знаете как с этим жить - сможете сделать общий swap на обе системы самостоятельно.

Открываете мануал к материнке и внимательно ищете сведения о том, что куда подведено электрически, в каком количестве. Если в мануале не описано - то продолжаете упорно искать в интернетах, что куда подведено. Начните с блок-схемы чипсета.

В частности, самый верхний M.2 вам недоступен вовсе. Потому что i7 10700k - это 10 поколение, мануал однозначно упоминает что верхний M.2 работает только при установке CPU 11 поколения (потому что слот подведён на линии PCI-E самого CPU)
Средний M.2 отключит один из разъёмов SATA в случае использования SATA M.2. Для NVME диска нет примечаний, до 4 линий от чипсета.
Нижний M.2 отключит два разъёма SATA при установке любого SSD в этот слот. Останутся ли у него 4 линии для PCI-E - не упомянуто, но скорей всего да.

У чипсета линий PCI-E более чем достаточно, аж 24 штуки. К чипсету подключены два M.2, один слот PCI-E x4, один слот x1, итого на всякую прочую мелочёвку остаётся ещё 11 линий.

учитывая количество линий на чипсете, я могу установить 1 видеокарту в режиме x16

Верхний PCI-E подключен к CPU, а не к чипсету.

https://ru.stackoverflow.com/q/721985/203622

Вот есть таблица с 1000 записей. В ней 9 колонок. На 3 из них есть индексы.

На такой мелочи без разницы. Перезапись такой крохи штука быстрая.

1. Возможно ли дозапись новой колонки в существующую структуру? Или под капотом происходит полное копирование всех данных в новую таблицу (табличное пространство?)

В зависимости от конкретного alter table add column.
Если вы добавляете add column score float default random() - то будем переписывать всю таблицу и перестраивать все существующие индексы.
Если default с константой и у вас pg11 или новее - то обновим в системном каталоге описание таблицы, а саму таблицу трогать не будем.
Если нет default (т.е. null) - то без оглядки на версию базы просто обновим описание таблицы и сами файлы таблицы трогать не будем.

2. Происходит ли пересоздание индексов?

да, если выполняется table rewrite

3. Происходят ли какие-то еще важные для понимания сути работы в БД процессы?

классическая история частых даунтаймов, что для операции нужна эксклюзивная блокировка. То есть для взятие блокировки не должно быть совсем никого, кто эту таблицу трогал в транзакции, начавшейся до alter table. Если у вас в это время работает какая-то аналитика на 10 минут или pg_dump - будут приключения, нужен statement_timeout

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

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...