Melkij

select distinct on (raw_id) raw_id, id, single_sum 
from tablename
order by raw_id, id desc

Может быть как обычно перепутал направление сортировки.

Это functional dependency. Если планировщик сможет свести ваши подзапросы или cte к уникальному индексу - functional dependency позволит ограничиться указанием только полей этого уникального индекса.

Встречный вопрос: а зачем вам такая группировка вообще? Для приведённых запросов бесполезна и лишь вредна.

Проверьте сколько запросов делает непосредственно браузер.

Например, фавиконка.

pgbouncer не имеет отношения к балансировке нагрузки. Вообще. Это pooler. В норме в transaction mode.

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

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 минимум. Нечего тестировать давно закрытые ошибки.

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

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

Нет.

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

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

query result rowtype does not match the specified FROM clause rowtype

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

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

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

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

?

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

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

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

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

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

Мой хрустальный шар совершенно верно показал.
Когда вы делаете 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 действительно колонка не удаляется никогда. Но это деталь реализации и к сути вашего вопроса отношения не имеет.