Возможно сохранить копию запроса с определенной таблицы?

Те настройки, изменение которых возможно только рестартом базы намеренно отмечены комментарием "change requires restart" в конфиге.
Более строго

select name from pg_settings where context = 'postmaster';

Или скомандовать pg_reload() и посмотреть в логе, что применилось, а что нет.

Как сделать конструкцию IN %(param_name)s необязательным параметром в строке sql если в качестве значения параметра был предоставлен пустой массив?

galaxy, если подставит литерал - то, в основном, такое только замедлит планировщик ненужной никому работой. А вот если там extended protocol с parse/bind/execute последовательностью - то запросто будут фокусы. Особенно вокруг переключения custom или generic планов.
Не надо пытаться запутывать планировщик. Он умный, но он тупой. Потому что ему нужно работать быстро, а не пытаться угадывать что же хотел сказать автор. Довольно много "оптимизаций" планировщика отклоняется именно по этой причине - мы не хотим замедлять абсолютно все запросы (некоторые и так планируются дольше чем собственно исполняются) чтобы исправлять один изначально странно написанный запрос.

Как сделать конструкцию IN %(param_name)s необязательным параметром в строке sql если в качестве значения параметра был предоставлен пустой массив?

Весьма не соглашусь, что "красивый синтаксис" в вашей идее, а не наоборот, в рядовом построении динамичного sql. Клиент запросил фильтр? Отлично, добавили его к sql запросу и сохранили параметр для bind. Просто, понятно, легко отслеживается, нет магических констант, которые как бы передаются параметрами, но игнорируются, легко планируется базой без фокусов, налагаемых ограничениями prepared stmt.

Да, собирать запрос по частям оптимально. Всевозможные query builder есть даже.

Как сделать конструкцию IN %(param_name)s необязательным параметром в строке sql если в качестве значения параметра был предоставлен пустой массив?

ArtiomK, а вот если присмотреться, то по ссылке развёрнутое объяснение почему не надо делать так как вы хотите.

Влияет ли количество PCI-E линий, на количество жестких дисков которое я могу подключить?

см. Serial ATA port multiplier чтобы понять глубину вариативности вопроса когда важен объём, а не пропускная способность.
Поищите описание серверов backblaze

Как отловить плавающий по времени запрос?

shared_blks_read - только про отсутствующие блоки в shared_buffers. Узнать, дошёл ли запрос до диска или был из системного page cache выполнен - никак. Поэтому однозначно не сказать, что не хватает памяти. Ну разве только у вас больше 75% ram отдано под shared buffers, когда в системном page cache мало что может уместиться.
Тем не менее факт говорит о том, что половину суммарного времени выполнения этих 100тыс запросов ждали IO. 1мс латентности, конечно, не предел мечтаний.
Дальше пока наблюдать, ждать проблемный пик и смотреть как изменятся цифры.

auto_explain для этих запросов ведь не фиксирует изменение плана?

На сколько быстро происходит пересчет hash индекса?

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

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

На сколько быстро происходит пересчет hash индекса?

Да, btree более универсален.
До postgresql 10 пользоваться hash было вообще невозможно, не логировались в wal и потому не реплицировались, не crash-safe. В 10 переделали. По размеру на самом деле тоже спорно, надо проверять на конкретных данных. Видел ситуации, где hash по объёму как btree получается. Ну и дедубликация btree в pg13 весьма хороша.

Как подключиться к postgresql который на 8080 порту?

Выясните сперва где всё-таки у вас база. pgadmin - это не база.
Подключитесь к базе и выполните

show listen_addresses ;
show port;

Почему не восстанавливаются резервные копии?

хмхм. А у вас pg_dump точно от этого форка postgresql вызывается?
На вид похоже, что сама база у вас отдельный форк для 1с, на самом деле не умеющего работать с postgresql. Но pg_dump записал создание этих нестандартных типов данных. При том, судя по "there are 2 candidates for ... function" - они ещё и различаются между тем что в дампе и тем что нагородили в этом форке.

Если у вас на самом деле установлено несколько разных pg_dump и теперь вызывается не тот модифицированный для форка, а, например, от оригинального немодифицированного postgresql - то это может объяснить происходящее.

Почему не восстанавливаются резервные копии?

Меня злит когда жмакают "Пригласить эксперта" на только что заданный вопрос. Впрочем, увидел по истории уведомлений, что это не ваших рук дело.

create database test_restore template template0;
затем покажите начало от pg_restore --shema-only -d "test_restore" "файл бекапа"

Почему не восстанавливаются резервные копии?

а вы pg_restore вызываете как заклинание, что ли? На мой взгляд DBA осмысленно вы могли написать только две опции из всех перечисленных.

В частности, --clean и должен генерировать ошибки, показанные на наскальной живописи выше.

PS: зачем останавливать предприятие на 8 часов для обновления ОС или базы - оставлю за скобками.

Как уведомлять в телеграмм от mdadm?

Свечку не держал, но я бы ожидал, что если оставить и адрес почты и program в конфиге - то сработают оба.

Почему не работает ограничение?

Откройте документацию postgresql и приведите оттуда цитату, прочитав которую вы решили, что под ваше выражение like должна подойти хотя бы одна из приведённых в вопросе строк.

Почему не создается правило с IF?

как вполне недвусмысленно задокументировано в create rule - поддержка returning добавляется в rule самостоятельно и вручную.

If you want to support INSERT RETURNING and so on, then be sure to put a suitable RETURNING clause into each of these rules.

суть как раз изучить создание правил

Тогда возьмите нормальное задание, а не непойми что из костылей и, несомненно, с вытекающими из этого неочевидными артефактами поведения.
Например, реализовать работу insert для сложного view.

Почему не создается правило с IF?

Создать правило, которое позволяет использовать в качестве значений атрибута только те значения, которые начинаются с русской буквы

Не вижу почему бы под это "задание" не подошёл бы обычный check constraint. Достаточно лишь трактовать "правило" не как "create rule", а как некую конструкцию, обеспечивающую заданное поведение.

Если же вы изучаете именно query rewrite system, а не криво написанное задание - то это будет крайне удивительно, но ответ тот же - почему бы вместо извращений с в принципе неподходящим инструментом не взять простой и понятный молоток?

Checkpoints are occurring too frequently?

тогда или не было sighup, или какая ошибка в конфиге (проверьте лог после reload) или параметр переопределён где-то ещё.

select sourcefile, sourceline from pg_file_settings where name = 'max_wal_size';

Вот это поможет найти где в конфигах задана настройка.

Почему в генерируемой колонке нельзя задать свойство STORED?

ну написано же прямым текстом: In MariaDB 10.2.0 and before .. the STORED keyword is not supported as an alias for the PERSISTENT keyword.
У вас какая версия mariadb? До 10.2.0 или после? Какой вывод? Есть в вашей версии ключевое слово STORED или нет?
Вывод номер два - какое ключевое слово используется в mariadb для обозначения не virtual generated column?

Почему в генерируемой колонке нельзя задать свойство STORED?

Цитата из документации выше.

Почему в генерируемой колонке нельзя задать свойство STORED?

то что у вас mariadb, а не mysql, как указано в тегах - надо оговаривать явно. И документацию смотреть именно к своей базе. Какая версия?
https://mariadb.com/kb/en/generated-columns/

In MariaDB 10.2.0 and before, the following statements apply to MySQL compatibility for generated columns:
The STORED keyword is not supported as an alias for the PERSISTENT keyword.