Melkij

pgpool - это в общем больно в поддержке. Лучше не надо.
Далее надо учитывать что автофейловер - это свой букет проблем и особенностей. И зачастую проблем от него больше, чем без него. Тест на понимание repmgr: "как именно выбирается новый мастер?". Обычно используется штатная потоковая репликация и мастер переключается вручную. Потому что основная сложность в определении, что надо переключаться, а не это кратковременный сбой, например, сети.
pgbouncer + haproxy вполне широко используются для балансировки по равнозначным репликам (и по нескольким pgbouncer если вы до гигабита трафика доросли). По равнозначным - то есть не надо на OLTP реплики пихать OLAP запросы аналитики - для этого нужны отдельные реплики специально для этого настроенные.

Упомянутый Александр Кузнецов patroni - во всяком случае я не смог спровоцировать его на split brain, поэтому в целом он мне нравится. Да и в паре мест в продакшене уже видел. Умеет и синхронные и асинхронные реплики, с haproxy дружит вполне штатно для опроса где нынче мастер и так авторами и используется.

Должно же быть восемь четырёхзначных блоков, а не шесть

Группы из одних нулей допустимо сокращать до ::

Настраиваете потоковую репликацию, через pg_basebackup снимаете копию, запускаете как реплику. Когда догонит ведующую базу выключаете мастер и повышаете реплику до нового мастера.
Даунтайм минута вне зависимости от объёма данных. Ну может ещё минута если понадобится рестарт мастера из-за смены wal_level, listen_addresses или max_wal_senders

https://wiki.postgresql.org/wiki/Streaming_Replication

А зачем вообще отправлять ошибку запроса на клиент?
Ошибке запроса самое место в логе и только там. Клиенту - HTTP 500 и "извините, не шмогла" написанное любым вариантом какой вам понравится.
Если требуется другое сообщение (или действие) для конкретной ошибки - ловите этот конкретный код ошибки. На допустимость логина обычно проверяют предварительным запросом, в апдейт on conflict пока не завезли. Плюс можно хапнуть advisory lock для устранения race condition и закатать всё в одну хранимку чтобы сэкономить на планировщике и сети.

Какие запросы к бд mysql можно считать быстрыми и какие медленными?

Быстрые это те, время обработки которых не мешает пользователю/бизнесу/всем_причастным.
Медленные - это соответственно те, которые мешают.

0.06 sec в консоли - это 6 сотых секунды, конечно.

Для веба значение имеет время рендеринга страницы пользователю. Хороший результат для backend'а - это 0,2 секунды на генерацию страницы. Это включая всё время обращений к кешам, базам данных и прочую логику построения страницы.

общее количество (а есть не общее?)

да есть - число знаков после запятой.

с которыми будет храниться данная величина (а может и не храниться?)

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

Как я понимаю, в этом поле должно хранится значение с 11 цифрами целой части и 10 дробной.

Нет.
11 знаков есть всего, из них 10 - для дробной части.

И почему запись вида DECIMAL(9,10) вызывает ошибку

Потому что число знаков после запятой не может быть больше общего числа знаков.

could not find driver

Скорей всего ошибка от PDO о том, что у вас не установлен модуль PHP с поддержкой запрошенной СУБД. Соответственно проверьте конфигурацию приложения, правильно ли указан DSN и конфигурацию PHP - установлен ли модуль для нужной СУБД.