Melkij

ORDER BY ID

хм.

Покажите explain (analyze,buffers) запросов. И покажите планы запросов с "ORDER BY ID + 0". И ещё

select * from pg_stats where tablename = 'table' and attname = 'column'

Я предположу что у вас вовсе не in медленный, а or ломает оценку планировщика, но в этом конкретном случае это оказывается неожиданным благом.

Зависит от схемы расположения реплик.

Каждое соединение репликации использует один из допустимых max_wal_senders хоста к которому подключается. Если вы настраиваете слоты репликации - то вдобавок вам нужно соответствующее число max_replication_slots на этом хосте.
pg_basebackup в свою очередь использует до двух коннектов max_wal_senders и до одного max_replication_slots (зависит от параметров запуска и версии)

Так если вы будете копировать все 10 реплик одновременно с помощью basebackup с одной мастер-базы - вам понадобится 20 max_wal_senders и 10 max_replication_slots. После запуска реплик будет использовано 10 max_wal_senders и от 0 до 10 max_replication_slots - смотря как настроите. Для каждой реплики отдельный слот репликации если вы хотите использовать слоты репликации.
Но это если настраивать репликацию без каскада.
Коннекты репликации считаются не по кластеру, а подключённые к конкретному инстансу. В случае каскада у вас легко может быть схема, например:
с мастера репликацию читают 3 реплики, с каждой из них репликацию получают ещё по 3 реплики - вот уже 9 реплик, а использовали только по 3 walsender на хост.

И при таком числе реплик весьма рекомендую делать каскад. И сеть на мастере поберечь и в случае переключения мастера придётся меньше баз рестартовать (primary_conninfo всё ещё меняется только рестартом всей базы, шанс у моего патча быть принятым в pg13 весьма призрачный)

Не надо использовать большой offset. Всё. В любой СУБД.
https://use-the-index-luke.com/no-offset
https://use-the-index-luke.com/sql/partial-results...

Никаких.

главное возможно ли при такой схеме гарантировать базам на кластере какие-то ресурсы (кроме диска)?

Вы даже io гарантировать так не сможете. Потому что WAL пишется строго один.

один пользователь не может выесть больше чем work_mem на бекэнд

Может. Запросто. Вы некорректно читаете документацию, там про это отдельно сказано.
И может №2 - set work_mem to '..'

Создал реплику, все реплицируется. Но у нее нет postgresql.conf

Всё у неё есть. Без config_file postgresql вовсе не запустится с ошибкой "could not access the server configuration file".
Ищите где потеряли.
show config_file;
на запущенной базе.

Вопросы оптимизации запросов не имеют смысла без указания используемой СУБД.

select ..., p.event_id is not null from events as e left join participations as p on p.user_id = ? and e.id = p.event_id

либо

select ..., exists(select null from participations as p on p.user_id = ? and e.id = p.event_id) from events as e

Сейчас версия postgis 3.0.0

https://postgis.net/2019/10/20/postgis-3.0.0/

Note that a major change in 3.0 is that the raster functionality has been broken out as a separate extension.

-- install these if you need them
CREATE EXTENSION postgis_raster;

если кратко: https://bugs.php.net/bug.php?id=62467

This can't be fixed; PHP doesn't control the way libxml2 does the allocations.

explain (analyze,buffers) с включенным track_io_timing покажите.

Варианты:
- вы проводите весь час времени не на сортировке, а где-то ещё о чём решили не писать. Соответственно вопрос неактуален и искать надо там где обронили, а не где светло.
- у вас несоответствующие настройки автовакуума (читай дефолтные)
- время занимает filesort, а от ssd у вас по ошибке стоят read-optimised.

Получается, что можно сделать свою виртуальную машину (суммирующий сервер)

Да.

не придётся собирать Raspberry Pi

Да.

не придётся арендовывать сервер

Нет.
MPTCP должны уметь хосты и принимающие и отправляющие данные.

На одном только отправителе - старый добрый LARTC и multihome routing со своими ограничениями

information_schema.sequences верный ответ, только стоит имя схемы так же учитывать чтобы не получить случайно несколько строк с разных схем.

SELECT increment FROM information_schema.sequences where sequence_name = 'example' and sequence_schema = 'public';

В postgresql 10+ можно обратиться к системному каталогу так

select increment_by from pg_sequences where schemaname = 'public' and sequencename = 'example';

До 10 релиза посмотрите в
select * from public.example;
(нет под рукой чтобы уточнить имя поля)

Но если не нужны детали реализации postgresql - то information_schema.sequences вероятно будет уместнее т.к. маловероятно будет изменяться в major релизах.

Ну раз уж позвали...

очень плохо документирован

Тут полностью согласен.

давно не обновляется и не поддерживается

А вот тут смотря что подразумевать.
pgq доступен для postgresql 12 - и для этого был ряд коммитов в pgq в этом году. Аналогично в этом году адаптировали скрипты для python3 вместо бывшего ранее python2. То есть вообще-то поддерживается если трактовать как усилия направленные на восстановление работоспособности.

или вообще не стоит использовать postgresql, а использовать специализированную базу данных?

Если вам нужна транзакционная очередь в postgresql - ничего лучше pgq мне неизвестно. Самописные реализации делаются просто и дают фейерверки в работе под нагрузкой. О том смотрите доклады моих коллег, ссылку на доклад Алексея вот уже привели.
Если вам нужна очередь без привязки к транзакциям в базе - имеет смысл посмотреть специализированные брокеры. Затруднюсь что-то подсказать конкретное.

Это синтаксис именно MS SQL.
Но sqlite его для совместимости тоже умеет: https://www.sqlite.org/lang_keywords.html

Следовательно, импортируйте сперва в sqlite, затем экспортируйте нормально. В нормальных стандартных кавычках - если ваш mysql в sql_mode=ANSI_QUOTES - или в специфичных для mysql апострофах `.

Если вы показываете стектрейс пользователю - то это ваша ошибка независимо от того какие данные там видны. Ошибки кода вы должны логировать себе, а пользователю показывать красивую страницу 500.

PDO при подключении даёт не ошибку, а генерирует исключение. Именно для того чтобы его было легко перехватить, как и любое исключение, и обработать.

Postgresql требует запуск сервера бинарниками скомпилированными ровно той же самой версии CATALOG_VERSION_NO что и был вызван initdb при инициализации datadir.
CATALOG_VERSION_NO активно изменяется в процессе разработки, никогда - после релиза major версии.

201909212 - заморожен для 12.0
201906161 - относится к 12beta2

Мы не гарантируем что beta версии будут бинарно совместимы с релизом. Если вы по глупости запустили в работу бета версию и теперь хотите оттуда достать данные - соберите и запустите кластер версии 12beta2. Затем pg_dumpall, поставить и инициализировать initdb релизной версии (12.1 сейчас), импортировать дамп туда.