Откуда 7 подключений к новой базе в RDS Amazon?

Системные:
autovacuum launcher
logical replication launcher
background writer
checkpointer
walwriter
Наверняка одна реплика и потому один штука
walsender
И наконец
client backend - тот самый процесс, который смотрит в pg_stat_activity

Угадал?
postgresql 10+, до 10.0 системные процессы в pg_stat_activity не отображались.

Как правильно сделать Restore в postgres 10.4?

Напишите что делаете. И уж точно напишите, в ответ на какое действие вы видите эту ошибку.

Это ли признак того, что на процессор подается слишком малое напряжение?

Но они работают в рамках одного TDP (теплового пакета). Но он ограничивает сверху, а не снизу или с обеих сторон.

Маркетинговый отдел intel уже давно не согласен с такой расшифровкой термина. Маркетинговый отдел расшифровывает TDP как

Thermal Design Power (TDP) represents the average power, in watts, the processor dissipates when operating at Base Frequency with all cores active under an Intel-defined, high-complexity workload

Что далеко не то же самое, что верхний лимит. Посмотрите например на 9900K с 95вт TDP, но уже 130вт в графе Thermal Solution Specification.

Добавление ОЗУ с другими характеристиками?

по меньшему таймингу

По большему.
Меньше тайминги - лучше. Модули разных характеристик добровольно согласуют только параметры худшего из модулей.
Или по меньшей частоте.

Debian шифрованный Boot и LVM, как настроить при установке?

А как вы себе представляете загрузку с зашифрованного /boot?
Пароль должен спрашивать как минимум загрузчик, а его невозможно загрузить, т.к. тот зашифрован.
Зачем делать /boot на LVM мне, впрочем, вовсе непонятно.

Ошибка PHP(7.2): Warning: date_format() expects parameter 1 to be DateTimeInterface, boolean given?

ну? Видите пустую строку? Конечно она не подходит под шаблон даты. Ищите откуда она приходит.

Ошибка PHP(7.2): Warning: date_format() expects parameter 1 to be DateTimeInterface, boolean given?

выведите рядом var_dump аргумента и результата date_create_from_format. С чётким разделением итераций цикла.

PostgresQl почему второй запрос быстрее первого?

good_beginer,

и у postgresql такая штука есть

ммм. Нет. Такого нет.
Есть WAL - это write ahead log. Это не doublewrite буфер. Это именно транзакционный лог. И у mysql есть транзакционный лог, только по другому принципу организованный.
Postgresql изменения данных пишет сначала в WAL и потом только в shared_buffers, не на диск. Затем фоновые процессы bgwriter и checkpointer (а если не справляются - то и сами backend'ы) сбрасывают изменённые страницы данных на диск сразу в то место, где те должны быть.

PostgresQl почему второй запрос быстрее первого?

good_beginer, а вы mysql от postgresql (см теги) вообще не отличаете? Это зря.
Ну и doublewrite буфер - это про операции записи и crash recovery.

PostgresQl почему второй запрос быстрее первого?

Ставить нормальные диски и адекватное для размера своей базы количество RAM и shared_buffers

PostgresQl почему второй запрос быстрее первого?

good_beginer, нет в postgresql query cache, никогда не было и разработчики старательно отвергают идеи это реализовывать. Тем более query cache нет уже и даже в mysql, те тоже наелись этого счастья и удалили.

Как организовать автоматическое резервное копирование баз PostgreSQL через cron?

ky0,

плюс не придётся каждый раз рестартовать сервис

А зачем и какой сервис рестартовать? cron изменения своих crontask'ов подхватывает сам, как пользовательских crontab, так и системные.

Как понять, что влияет на скорость выполнения запроса с массивом?

explain (analyze,buffers,verbose) лучше. И лучше с track_io_timing
Будет видно чего и как долго читали.

И смотреть какой процент строк попадает под фильтр, может индекс и не нужен, т.к. всё равно читаем почти всю таблицу.

Как запретить системе доступ к харддрайву?

купить hotswap корзинку и физически перетыкать диск. Это чтобы наверняка. Ну или тумблер на питание дисков врезать можно.

Как расширить файловую систему на RAID томе mdadm?

Да, можно. Так массив в общем-то и расширяется, наживую переписывать таблицу разделов как раз лучше не надо, но можно. Добавляемый том в массиве должен быть не меньше Used Dev Size (mdadm -D /dev/md0), больше - на здоровье. Лишнее место использоваться только до --grow --size=max никак не будет.

Как расширить файловую систему на RAID томе mdadm?

Для плановой замены на более большие диски вероятно лучше подойдёт вот это сочинение: https://ru.stackoverflow.com/a/637847/203622
Обычно не проблема одновременно воткнуть все 4 диска.

Как конвертировать/сохранить Unicode в UTF8?

См. sql-инъекции. Обновлённая версия вопроса - как раз про это и это является настоящей причиной наблюдаемого поведения.

MySQL максимальный размер varchar - 255. При создании я указал длину 9000. И поместил туда текст такой длины. И он сохранился. Почему не обрезался?

Также учитывайте, что текст свыше 255 символов занимает L+2 байта.

И внимание на многобайтовые кодировки.
Число в скобках у varchar - число символов. Предел же в 64 килоБАЙТа. Что далеко не всегда одно и то же. Для utf8mb4 вы гипотетически сможете записать от 16к до 65к символов - в зависимости от того, что именно пишете.

Ну и конкретно для varchar важнейшая деталь - 64кб - это не его предельный размер. Это hardcoded лимит на размер одной строки таблицы, включающий в себя все колонки этой таблицы. Невозможно иметь два varchar по 40кб

Как получить список чисел отсутвующих в базе PostgreSQL?

И опять вы про какую-то другую СУБД.

если есть то какого типа (уникальный, кластерный)?

primary key, btree.

есть много свободной оперативки для построения хэш таблицы.

Не учитывается планировщиком. Есть work_mem - влезаем - берём его. Нет делаем disksort. Дисковой сортировки не было. hash join вовсе не умеет temp files и всегда в памяти. Если планировщик считает, что не влезет в work_mem - то предпочитает другой план.

Как получить список чисел отсутвующих в базе PostgreSQL?

Руслан, вы про какую-то другую СУБД. Нет в postgresql никакого tempdb, тем более разделяемого по кластеру между пользователями в оперативке. work_mem выделяется динамически в приватной памяти каждого отдельного backend под каждый отдельный того требующий узел плана запроса.

быстрее чем с диском (хотя если диск SSD то разница не сильно большая).

О да, разница всего лишь порядками измеряется.

Выше я забыл дописать - 100% cache hit по shared buffers. С дисков не читалось ничего и not in оказался всё равно в полтора раза быстрее. Потому что миллион index lookup всё равно имеют свою цену. И это на index only scan, т.е. для проверки mvcc мы страницы таблички не поднимали.
Запрос с except у меня получается посередине по скорости. А чисто алгоритмически - сюда бы неплохо merge join встал, о чём уже упоминал. Одну табличку читать по индексу уже отсортированную, опорную последовательность мы заранее может гарантировать последовательность значений. То есть на сортировку ресурсов не тратим вовсе.