Создать несколько таблиц или попробовать унифицировать?

Отдельно из опыта разработчика как раз системы, завязанной на большое число сторонних API: сразу предполагайте, что API будут отвечать неадекватно и вам будут необходимы подробные логи уровня коммуникации сервисов: датавремя, какой запрос сделали к api, какой ответ получили. Если говорим о HTTP REST - то сохранять буквально весь HTTP request как он уходит текстом и сохранять весь пришедший ответ с заголовками, время отправки запроса, время получения ответа.

Как создать триггер, который после добавления записи в 1 таблицу создаст n количество записей в другой таблице?

А в чём у вас затруднение? Не написать after insert триггер? Не сделать insert ... select from generate_series(1, NEW.devicecount, 1)? Или даже for loop?

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

В postgresql есть simple query протокол - идёт текстовый запрос и дальше развлекается база.
Есть extended protocol, состоящий из parse пакета со структурой запроса и метками под параметры, затем идёт один или несколько bind и execute пакетов. В bind передаются значения параметров, execute соответственно запускает выполнение запроса. В сам текст запроса актуальные значения параметров при этом никогда не вставляются за ненадобностью. Так же известный как server prepared statements api.

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

Это и есть query как оно пришло от клиента. Не уверен что можно дотянуться до соответствующих bind.
Но триггер же, можете из OLD и NEW достать информацию об изменяемой в данный момент строке.

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

Те настройки, изменение которых возможно только рестартом базы намеренно отмечены комментарием "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, а не криво написанное задание - то это будет крайне удивительно, но ответ тот же - почему бы вместо извращений с в принципе неподходящим инструментом не взять простой и понятный молоток?