Melkij

Как-как. Вызывается некоторая хэш-функция для значений ключа партицирования, её результат делится нацело на modulus, строка попадёт в ту партицию, для которой совпадает remainder.

create table part (i int) partition by hash (i);
create table part_0 partition of part FOR VALUES WITH (MODULUS 2, REMAINDER 0);
create table part_1 partition of part FOR VALUES WITH (MODULUS 2, REMAINDER 1);
insert into part select generate_series(1,10);
select * from only part_0;
select * from only part_1;

на слишком малых выборках хэш ожидаемо может быть не столь равномерно распределён.

Берёте pgbackrest.
Ну или walg или barman какие.

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

архивные логи ДО-момента backup'а уже не нужны

до позиции LSN на момент запуска basebackup, самого старого из тех, который по вашей политике резервного копирования нужно хранить.

select (select j->>'name' from jsonb_array_elements(jsonb_field) as j where j->>'custom_twine' = 'custom_38') from tablename

Все unquoted identifiers принудительно приводятся парсером в нижний регистр.
quoted identifiers - используются как есть.
https://www.postgresql.org/docs/current/sql-syntax...

при наличии уникального ограничения по phone

insert into desc (phone, name, nickname)
select phone, name, nickname from src
on conflict (phone) do update name = excluded.name

create temp table import_data (...);
copy import_data from '/path/to/file' (format csv, ...);
insert into tablename (...) select .. from import_data where not exists (select from tablename where tablename.phone = import_data.phone) on conflict do nothing;

alter user .. set idle_in_transaction_session_timeout = ...

max_client_conn в конфиге баунсера - это максимальное число возможных подключений от клиентов к самому баунсеру.
Если у вас max_client_conn стоит, например, 100, а каждый из 20 бекендов попробует открыть по 10 соединений с баунсером - то первая сотня подключений будет успешна, остальные получат ошибку "no more connections allowed (max_client_conn)"
max_client_conn ставится в 10000 и про него надолго забываем. Штука фактически бесплатная, libevent хорошо умеет с таким работать. Но требуется выставить корректный open file limit. Каждый коннект - это файловый дескриптор, если не скорректировать настройки ОС - то будет неприятный сюрприз.

Далее, max_connections базы оставить как есть. Максимум в 100 процессов базы на всего 8 ядер - это и так довольно-таки много, но и урезать смысла нет.
max_user_connections не трогать если нет причин для этого.

pool size 20 на всего лишь 8 ядер CPU может быть чрезмерно. Но далее нужно смотреть уже мониторинг. Сколько реальных процессов базы в работе, очередь ожиданий на баунсере, хватает ли баунсеру процессорного времени (тут скользкий момент, баунсер строго однопоточный и может упираться в производительность одного ядра CPU)

https://github.com/postgres/postgres/blob/REL_15_S...

We allocate one map byte to each page, allowing us to record free space
at a granularity of 1/256th of a page. Another way to say it is that
the stored value is the free space divided by BLCKSZ/256 (rounding down).

один байт FSM отражает страницу данных.

Такой текст ошибки используется только в одном месте и суть его заключается в том, что в pg_collation нет такой строки.
Что через https://www.postgresql.org/docs/current/collation.html приводит к вопросу: существует ли локаль en_US.utf8 у вас в системе, чтобы её использовать?

Если нет - создайте локаль. Затем select pg_import_system_collations('public'); должно быть достаточно

если кратко: https://github.com/postgres/postgres/blob/REL_15_S...

только требуемые строки, в select for update (и родственниках) это видно отдельным LockRows плана выполнения