Melkij

PHP PDO несовместим с max_prepared_statements фичей баунсера.

PDO отправляет deallocate как SQL запрос, а не как команду протокола.

если clock это unixtime, а так же именно по нему и хотим партиционировать в дальнейшем:

begin;
set local statement_timeout to '100ms';
alter table history add constraint partition_key check (clock < :N) not valid;
commit;
alter table history validate constraint partition_key;
begin;
set local statement_timeout to '100ms';
alter table history rename to history_old_data;
create table history (...) partition by range (clock);
alter table history attach partition history_old_data for values from (minvalue) to (:N);
create table history_part_... partition of history for values from (:N) to (...);
commit;

:N - некая дата в будущем, до неё данные будут писаться в старую 5тб табличку, после - в новую партицию. Если до выбранного :N не успеете завершить миграцию - то удалить check constraint, иначе запись, конечно, встанет.

create extension pg_trgm;
create index concurrently db_url_trgm_idx on db1 using gin ("Url" gin_trgm_ops);

https://www.postgresql.org/docs/current/pgtrgm.html

limit штука простая. LIMIT [offset,] row_count означает, что запросу нужно прочитать offset + row_count строк из результата запроса, затем отбросить первые offset найденных строк и вернуть то что осталось. Вот и вся логика. Если после откидывания offset строк в результате не осталось - будет возвращено пустое множество.

Необходим свой комплект ALTER DEFAULT PRIVILEGES для каждого пользователя, который будет создавать объекты в базе.
Это раз.

Два - идея вообще стабильно работать будет только для CRUD. Всякие alter table требуют быть владельцем таблицы либо быть в группе владельца (не в общей с владельцем группе, а именно чтобы владелец таблицы был в группе пользователя).

Подумайте над организацией процессов. Наименее проблемно будет, если у вас будет только один пользователь, который создаёт или меняет схему данных, а ro (select только) и rw (select/insert/update/delete) пользователей может быть много. Всё остальное к приключениям.

В postgresql создаётся физически новая версия строки при update (с обновлением всех индексов либо hot update если применимо) даже если ни одно поле не меняет своё действительное значение. Есть встроенный триггер suppress_redundant_updates_trigger, который можно повесить на таблицу, тогда ничего действительно не меняющий в данных update будет пропускаться.

Если меняется хотя бы одно значение - оптимизации не подлежит, должна быть записана новая версия строки в таблицу (чтобы MVCC обеспечить). Если возможно, оптимизация HOT update исключит сопутствующее обновление индексов.

Вариант записи допустимый, а вот вызываете неверно:

melkij=> create or replace function myfunc()
returns setof record
as $$
declare
res record;
begin
execute 'select 1' into res;
return next res;
execute 'select 2' into res;
return next res;
return;
end;
$$
language plpgsql;
CREATE FUNCTION
melkij=> select * from myfunc() as s(i int);
 i 
---
 1
 2
(2 строки)

melkij=> select myfunc();
ERROR:  materialize mode required, but it is not allowed in this context
КОНТЕКСТ:  PL/pgSQL function myfunc() line 6 at RETURN NEXT

PS: прямой return query (или return query execute если это реально необходимо) будет проще и нагляднее перекладывания return next через лишнюю переменную.

Ни один из перечисленных.
Для простого SELECT нужны AccessShareLock на таблицу/индексы/etc. row-level блокировки не применяются за ненадобностью.

melkij=> \df to_tsvector
                                  Список функций
   Схема    |     Имя     | Тип данных результата | Типы данных аргументов |  Тип  
------------+-------------+-----------------------+------------------------+-------
 pg_catalog | to_tsvector | tsvector              | json                   | функ.
 pg_catalog | to_tsvector | tsvector              | jsonb                  | функ.
 pg_catalog | to_tsvector | tsvector              | regconfig, json        | функ.
 pg_catalog | to_tsvector | tsvector              | regconfig, jsonb       | функ.
 pg_catalog | to_tsvector | tsvector              | regconfig, text        | функ.
 pg_catalog | to_tsvector | tsvector              | text                   | функ.
(6 строк)

действительно не существует такой функции.

Поправьте тип данных поля config на ожидаемый regconfig.

$_SERVER['REMOTE_ADDR']

Возможны варианты конфигурации, при которых адрес клиента необходимо получить каким-то другим способом, а не из REMOTE_ADDR, в этих случаях следуйте инструкции хостера или вашей группы эксплуатации.

melkij=> select 'hello'::xml;
  xml  
-------
 hello
(1 строка)

melkij=> select '<foo>hello'::xml;
ERROR:  invalid XML content
СТРОКА 1: select '<foo>hello'::xml;
                 ^
ПОДРОБНОСТИ:  line 1: Premature end of data in tag foo line 1
<foo>hello
          ^
line 1: chunk is not well balanced
<foo>hello

есть проверка.

Если вам нужно проверить, что это не просто валидный xml, но целый документ - добавьте check constraint с проверкой на columnname is document

Как-как. Вызывается некоторая хэш-функция для значений ключа партицирования, её результат делится нацело на 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, самого старого из тех, который по вашей политике резервного копирования нужно хранить.