Melkij

Тут спецификации PCI-E 6.0 обратно совместимы со всеми предыдущими PCI-E включая 1.0, а вы о 3.0 vs 3.1...

Да, должен работать.

Нет.

PS: такие мелкие партиции скорей всего ухудшат производительность.

Вы запросили select *, затем сказали что record возвращаемые функцией соответствуют по структуре одному полю типа numeric.
Всё, в самом прямом смысле

query result rowtype does not match the specified FROM clause rowtype

pgadmin вовсе ни при чём, на запрос закономерно удивляется сам postgresql

На залежавшиеся железки бывают иногда неадекватные ценники.
Для его родного 2013 года характеристики не самые плохие. Насколько ретроспективно могу сходу найти - конкурировать с intel DC S3700 хотели. Впрочем ценник в $1300 и тогда был бы неадекватен, не то что сейчас (каких-то MSRP не нашёл для ориентира).

Чтож, зависит от того что именно вы хотите сделать.

PostgreSQL позволяет сделать полностью собственную реализацию типа данных. Которая будет себя вести так как вы захотите - но всю эту логику вы должны разработать сами на C. Потому у create type и довольно объёмная документация.

range типы - это диапазоны. Например, дата бронирования номера гостиницы. Таблица бронирований, одно поле с диапазоном дат tsrange и exclude constraint - всё, база проконтролирует, что даты бронирования не пересекаются.

перечисления - это обычно подразумеваются enum. Но для вашей задачи это не подходит. enum - это фиксированный набор из строк.

что-то похожее на штатные типы данных, но с ограничениями - вы хотели найти не create type, а create domain:

CREATE DOMAIN smallint_between_10and200 AS smallint CHECK(value >= 10 and value < 200);

Всё, теперь в таблицах вы можете использовать тип данных smallint_between_10and200, в который тем не менее записать что-то не из диапазона 10..200 будет невозможно.

Оператор сравнения в plpgsql такой же как в SQL. is null для проверки является ли значение null и = для равенства.

Для изменения вставляемой строки вы должны модифицировать переменную new, а не пытаться уйти в бесконечную рекурсию выполняя аналогичную вызвавшему триггер операцию.

В таблице items 12 млн записей, в using_items 11 млн. Разумеется количество гипотетическое и маловероятное.

Да нагенерируйте и посмотрите explain analyze. Были бы действительно объёмы, а не всего-то десяток миллионов строк.

not in дорог из-за требования стандарта по части обработки NULL в not in и отсутствии специальных оптимизаций для этого случая. Может быть оптимизация появится.
not exists оптимален.
через left join план может быть идентичным not exists

По виду похоже на дважды закодированный json. То есть
$out = json_decode(json_decode($var), true);

select k, count(*) from tablename join  jsonb_object_keys(data) as k on true group by k

?

Если материализованное view - то refresh materialized view
Если не материализованное - то закешировано быть не могло. Смотрите определение view и исследуйте, откуда строка в резуультате этого запроса получается.

Ну я бы тоже удивился если бы меня попросили что-то сделать в 6:320. Каким стандартом этот формат времени описывается?

Можем ли мы быть уверены, что в следующей конструкции обновление обязательно произойдет (считаем что SELECT вернул какие-то данные)?

Нет, не можем.
Два конкурентных запроса могут увидеть одни и те же версии строк в cte (не пересекутся на читающих блокировках даже с конкурентными писателями т.к. mvcc) и затем пойдут обновлять одни и те же строки. На блокировках обновления строк их транзакции и сериализуются. Кстати, можно и deadlock словить если строк к обновлению будет несколько и они вернутся из запроса в разном порядке.

приостановить запрос и посмотреть что будет, если произойдет X?

gdb может приостановить всё что угодно. Правда далее уже интересный момент что надо найти куда именно break point ставить.

Посмотрите в vgdisplay есть ли Free PE. Если 0 - расширять просто нечем.

Если free есть - то lvresize или lvextend. Затем расширить файловую систему (resize2fs для ext2/3/4 который у вас вероятно и есть)
Если free нет - то необходимо добавлять новый диск или уменьшать другие разделы. Например, /home . Впрочем, судя по его размеру и 45мб занятых - вы разрезали диск неверно для своей задачи (а зачем вообще резали отдельно /var и /home ?). Может лучше будет вовсе перемонтировать раздел с /home куда-нибудь, скопировать в корневой /home данные и удалить этот том полностью.
Если /home вам нужен отдельный - то опять же resize2fs или какая у вас там файловая система стоит. Сжимаете до какого-то размера (если возможно), проверяете что сжалась, затем уменьшаете логический том (lvresize). Имеет смысл запросить resize2fs меньше размера на который хотите уменьшить раздел. затем после lvresize ещё раз вызвать resize2fs и расширить раздел обратно - чтобы случайно не ошибиться на пару мегабайт и не повредить этим файловую систему.

Мой хрустальный шар совершенно верно показал.
Когда вы делаете add column columnname text - вы получаете NULL во всей этой колонке. Разумеется сразу после этого вы поставить NOT NULL не можете никак. Любая строка нарушает это ограничение и база отказывается ставить NOT NULL.
Когда вы делаете add column columnname text NOT NULL - чтож, это может сработать в одном случае - у вас пустая таблица. Тогда ни одна строка не нарушает NOT NULL ограничение, у вас просто 0 строк. Если хоть одна строка есть - это невозможно. Вы просите default NULL и одновременно NOT NULL - так не бывает. В сообщении об ошибке говорится именно о добавляемой в этот момент колонке, не о какой-то другой существовавшей ранее.

Вы должны указать какой-то не NULL default если хотите поставить NOT NULL на создаваемое поле. Либо очистить таблицу.
Либо создать без NOT NULL, заполнить поле, потом уже делать NOT NULL.

В postgresql действительно колонка не удаляется никогда. Но это деталь реализации и к сути вашего вопроса отношения не имеет.