Melkij

Казалось бы, ответ очевиден

Нет, не очевиден. См. близкие Single Thread попугаи.
У E3-1225 v5 чуть меньшие частоты, но архитектура новее на 3 года. С классическими 5% в год от интела всё равно разница есть.
Плюс скорей всего здесь больше влияния имеет латентность памяти.

Client does not support authentication protocol requested by server; consider upgrading MySQL client

Что-то непонятно в сообщении? Обновите клиентскую библиотеку.

Если речь о mysql 8.0 - то вторая возможность поменять default-authentication-plugin, который был в 8.0 изменён.

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

innodb требует, чтобы индекс на referenced (на которую ссылаемся) табличке уже был. Индекс на табличке которой alter table делаем будет неявно создан если отсутствовал. Таким образом innodb требует наличие индексов на обоих концах FK.

У вас просто терминал узкий для вашей выборки.
Широкие результаты часто удобнее читать в широком виде, который переключается с помощью команды \x в psql:

melkij=> select generate_series(1,3);
 generate_series 
-----------------
               1
               2
               3
(3 строки)

melkij=> \x
Расширенный вывод включён.
melkij=> select generate_series(1,3);
-[ RECORD 1 ]---+--
generate_series | 1
-[ RECORD 2 ]---+--
generate_series | 2
-[ RECORD 3 ]---+--
generate_series | 3

man ssh
ssh ... -i /path/to/private_key

mysql не умеет конвертировать значения при смене типа на несовместимый.
Поэтому необходимо добавить новое поле, обновить всю таблицу, удалить старое поле и переименовать новое в старое.

Для конвертации из числового unixtime в datetime есть подходящая функция FROM_UNIXTIME, поэтому обновление таблицы будет таким:

update tablename set new_datefield = FROM_UNIXTIME(old_int_unixtime);

Зависит от требований к бекапам.
Если нужен point in time recovery, т.е. возможность восстановить состояние кластера на какую-то произвольную транзакцию - то это pg_basebackup + архив WAL.
Чтобы не собирать конструктор вручную - есть barman. Если бекапить хотите куда-то в s3 - то проще будут wal-e или wal-g
Одну базу в отдельности так бекапить и восстанавливать не выйдет, только весь инстанс целиком. Объём бекапа = объём всего инстанса + объём всех WAL от начала basebackup до нужного момента восстановления, количество wal зависит от вашей пишущей нагрузки.

Если достаточно логических слепков данных, например, ежесуточных - тогда да, pg_dump. Восстановление соответственно только на момент начала снятия дампа.
Типично делается pg_dumpall -g для сохранения глобальных данных кластера - пользователей, tablespace, имён баз и отдельные pg_dump для тех баз которые надо бекапить.
Формат часто custom делается, т.к. он штатно сжимается и позволяет через pg_restore восстанавливать определённые объекты из дампа, а не только всё целиком как текст через psql. Для гигабайтной базы смысла нет, а для баз побольше имеет смысл делать формат directory в несколько потоков.

Разница в количестве вопросов. Вернее в приоритете этих вопросов. How the Installer Works, только параметром priority отличается эти пункты меню.

Для цели резервного копирования вам нужна не вторая база, а само резервное копирование. То есть pg_basebackup и архив WAL с момента старта basebackup до момента на который вы хотите восстановить состояние базы. Посмотрите barman как более готовую штуку для этого. Или wal-e/wal-g, которые проще в настройке сами по себе - если вы бекапитесь куда-нибудь в совместимое с ними место.

Если вам нужно не резервное копирование, а запасная машинка на случай проблем с первой - то вам нужна репликация. Штатная потоковая репликация отличная стабильная штука. Надо пояснять чем отличается резервирование от бекапов?

Писать кодом в две разные базы - как раз идея плохая как для резервирования, так и для бекапов. Записали изменение в одну базу, во вторую не смогли с какой-нибудь мелкой ошибкой вроде сети моргнувшей. Что делать будете? А ничего хорошего. Корректно писать в несколько мест - задача не слишком тривиальная и нужно что-то сочинять, например протокол двухфазного коммита.

Мультимастер СУБД - это такая замечательная штука, которую все хотят и ни у кого пока не получилось.
Потому что есть такая штука как CAP теорема, весьма мешающая сделать серебряную пулю.

Ладно, ближе к делу.
Самая большая проблема с автоматическим failover СУБД - решить, что уже пора переключаться. Для чего необходимо выяснить, а что вообще происходит, не развалилась ли сеть, не вернётся ли через пару секунд мастер обратно - если в сети в результате окажется два мастера, то нет никакого разумного способа определить, где данные актуальны. Худшее что можно представить - это split brain: когда часть приложений ходит в один мастер, часть в другой и данные стремительно расходятся в разные стороны. Есть такая байка про гуглдиск "у нас всё отказоустойчиво, все данные хранятся в 4 экземплярах. Правда, у нас была авария и мы теперь понятий не имеем, какая из копий актуальная"
Переключение мастера на 90% - решение административное и человеческое. Автоматика же добавляет головной боли. Зачастую - больше головной боли, чем без неё. Особенно если железо адекватное серверное, которое "вдруг" выпадает очень редко.

Обычно автоматики нет, и есть детальная инструкция по переключению мастера БД, по которой и в ночи можно переключиться.

Если всё ещё хочется походить по граблям - посмотрите patroni. Есть пара кластеров с ним на поддержке, при наличии мониторинга особых проблем не припоминаю. До split brain по крайней мере не придумал как довести, вроде все варианты прикрыты. В худшем случае в readonly уходит.

Ошибка в используемой библиотеке. Так запрашивать версию базы нельзя.

Ломается именно на 10 очевидно из-за смены политики нумерации, до 10 было x.y.z, где x.y - major версия, начиная с десятки релизы нумеруются x.y, где major версия только первая цифра. Глупый код пытающийся распарсить номер находит не то что ожидает.

Вероятно, полтора года спустя с релиза postgresql 10.0, библиотеку уже исправили. Хотелось бы надеяться что на использование специально для этого предназначенной current_setting('server_version_num'), а не опять костылём вокруг не предназначенной для того version()
Копать соответственно в сторону обновления версии библиотеки. Если никак - откатываться на postgresql 9.6.

Если curl_exec вернул управление и не выставил curl_errno - значит запрос выполнен.

Между состояниями "запрос выполнен" и "загрузилась страница" - разница как между колесом и машиной. Необходимо уточнение что такое "загрузилась страница".

Я изучал эту пару:
"The C Programming Language" Dennis Ritchie, Brian Kernighan
"2lst Century С" Ben Klemens

Но важная оговорка - я полез в C уже имея многолетный опыт разработки на других языках. Обе книги весьма затруднительно назвать учебниками для начинающих.

Нужен explain (analyze,buffers), сильно желательно с track_io_timing = on в конфиге.

параметр work_mem на данный запрос не может оказывать почти никакого влияния

Оказывает. Если планировщик решит, что work_mem не хватает - не будет hash join. Для сортировки 27кб, очевидно, без разницы.

Впрочем, зачем вам вообще join подзапроса где одна только группировка подзапроса занимает половину времени ответа? Вам простой exists нужен.

SELECT "t1".* FROM table_1 as t1
where exists (select 1 from table_2 as t2 WHERE t1.primarykey=t2.session)
ORDER BY "starttime" DESC LIMIT 20;

А дальше know your data. Если по starttime DESC быстро находятся нужные exists - будет хорошо. Если exists мало - стоит подумать, а не денормализовать ли этот признак в table_1 с триггером для консистентности в table_2 и частичным индексом по starttime where t2_exists.

Поля session и primarykey в формате uuid

Не очень хорошая идея. Оно и сильно медленнее при сравнении относительно bigint (особенно если речь о varchar, а не uuid типе данных) и из-за случайного распределения несколько сбивает с толку статистику планировщика.

Формат условия "функция(поле_таблицы) оператор" в принципе не может использовать индекс по этому полю. Если нет других селективных индексов - гарантированный fullscan.
Формат условия "поле_таблицы between ? and ?" - может использовать индекс.

Выводы?
3 диапазона через or или, возможно, эффективнее будет 3 union all в каждом по одному диапазону. Не помню насколько адекватно нынче mysql ведёт себя с or.