Melkij

sudo - запуск команды от имени пользователя ОС.
Пользователь ОС не имеет совсем ничего общего с пользователем в БД. Пользователя ОС вы не создали, ответ sudo закономерен.

Для использования psql sudo не нужен. Нужны настройки pg_hba.conf и сам psql. Например, psql -U user1 database1

Нужно получить диапазоны цен, где максимальная цена больше определенного числа.

Мне кажется вам нужен вовсе:

select product_id, min(price), max(price) from prices group by product_id having max(price)>= ?

А отвечая на вопрос в лоб - lateral join'ом перенести подзапрос в секцию from и всё.

Если база большая - pg_upgrade в link mode. В документации шаги вполне описаны. Желательно иметь реплику на всякий случай.
Если база маленькая - pg_dumpall и импортировать в новую версию из дампа. Собственно всё просто: запустить новую базу на отдельном порту, снять дамп, залить дамп, остановить старую базу,, перезапустить новую на нужном порту.

Просто запустить бинарники одной major версии на datadir другой major версии - не получится.

Для обновления в пределах одного сервера нужны бинарники обеих версий СУБД. Инструкцию по установке уже расписал Alexey Dmitriev

не ниже 10.1(на локалке у меня 10.1) или лучше ставить последнюю 12?

10.11 минимум. Нечего тестировать давно закрытые ошибки.

Идём в спецификацию и читаем:

Max CPU Configuration 1

У них вообще нет линков для межпроцессорного взаимодействия. Емнип, как и контактов под это дело вообще у 1155 сокета - строго 1S сегмент.

RLS то что вы хотите услышать.

Отдельный сервис между базой и неподконтрольными вам клиентами - то что вам необходимо сделать. База в мир открыта быть не должна. DoS делается довольно просто даже без знания паролей, а уж с доступом...

Тут спецификации 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

?