Почему запрос с IN в СУБД PostgreSQL выполняется значительно медленнее аналогичного запроса с OR?

ну так и где вы потеряли этот desc? Добавьте раз нужен.
Сортировка по bigint не изменяется относительно сортировки по bigint+0 потому что сортируются всё равно по результирующему bigint.

Почему запрос с IN в СУБД PostgreSQL выполняется значительно медленнее аналогичного запроса с OR?

order by id + 0 я использовать не могу

Какой это у вас тип данных, что для него определён оператор сложения с числом, но при этом при сложении с константой нарушается сортировка?
asc/desc неважно.

А начните, как я уже сказал, с поднятия statistic target.

Переключение форматирования в psql - команда \x

Почему запрос с IN в СУБД PostgreSQL выполняется значительно медленнее аналогичного запроса с OR?

Всё как я и подумал. Хоть данные статистики и не показали.

Планировщик основываясь на MCV списке статистики решил, что требуемых source в таблице достаточно много. Потому решил исключить сортировку данных и идти по индексу по полю id, выбрасывая по пути в рантайме неподходящее. Реальное распределение данных оказалось однако не таким. И пока набрали limit записей - прошло уже много времени и random io.

Как нетрудно заметить - все три других плана запросов сортируют результат в рантайме и используют другой индекс.

Можно попробовать поднять statistic target для поля и пересобрать статистику. Вероятно вправит оценку планировщика. Или оставить order by id + 0. Это известный костыль для этой вполне известной грабли.

Почему запрос с IN в СУБД PostgreSQL выполняется значительно медленнее аналогичного запроса с OR?

Bavashi, нет, не странно. Нигде не сказано, что эквивалентные на вид запросы база и выполнять должна одинаково. Напротив, вполне логично допускать что планы могут быть выбраны разные.

Для определённых выводов не хватает данных.

Почему не отрабатывает изменение правил доступа по умолчанию на уровне схемы?

Однако если в правах доступа разрешить не только чтение, а всё (ALL), проблема исчезает.

Сомнительно. Скорее предположу разницу в том, кто именно создаёт таблицы и для кого ALTER DEFAULT PRIVILEGES объявлены.
Соберите воспроизводимый пример из create user, ALTER DEFAULT PRIVILEGES, \ddp, create table и \dp

Сколько нужно создавать слотов для 10 реплик при потоковой репликации?

Полагал что слот - это как в логической репликации - издатель/подписка. Поэтому думал что publisher примерно как слот. А реплики - примерно как подписчики.

В логической репликации publisher может быть один, но каждый подписчик создаёт свой отдельный слот логической репликации на мастер-базе. Да, они тоже - replication slots.

Сколько нужно создавать слотов для 10 реплик при потоковой репликации?

Для каждой реплики отдельный слот репликации если вы хотите использовать слоты репликации.

Я об этом так же написал в ответе.

- replica-1 с 1 БД, полученной с мастера

Потоковая репликация postgresql - всегда полная копия всего инстанса. Не может быть чтобы реплицировалась одна БД с кластера.

Мы не используем слоты репликации для потоковых реплик, увеличиваем вместо этого wal_keep_segments. Здесь оценка риска: без слота репликации реплика может отстать и её надо будет выключать и копировать заново. Слот репликации же будет удерживать WAL от удаления бесконечно пока их не прочитают. Типичная история - мастер лёг потому что кто-то забыл удалить слот репликации и место на диске в итоге кончилось. И вот между "лёг мастер" и "реплика работает но показывает старые данные" - выбор как-то обычно в сторону второго сценария, влияние на сервис менее болезненное.
Мониторить репликацию разумеется надо, но всё равно почему-то it happens.

Как изменить путь к логу postgresql на работающей реплике?

Aborigen1020, зависит от решения администратора либо сопровождающего пакета. Конфиг может лежать в $PGDATA или абсолютно где угодно - но во втором случае его местоположение должно быть указано аргументом при запуске базы.
Второй вариант характерен для debian/ubuntu пакетов, в centos принято в $PGDATA оставлять.

Offset не работает с подзапросами?

И дальше что? Думаете кто-то может догадаться о чём вы вообще говорите если вы оставляете только какие-то фрагментарные обрывки сведений?

Offset не работает с подзапросами?

Значит смотрите explain (analyze, buffers, verbose)

Какие инструменты есть в postgres для разделения ресурсов между пользователями?

Для недоверенного кода - нет. Для своих сервисов - организационным способом.

Как организовать репликацию баз данных с одним и тем-же именем в Postgres?

мастера не трогаем. На хосте под реплики делаете в разные места три basebackup -R, правите в конфигах номера портов, запускаете 3 разных экземпляра базы. Каждый из них смотрит на своего primary

Как быстро сортировать в большой таблице по часто изменяемому полю?

Александр Кубинцев,

Buffers: shared hit=79631 read=1385187 written=4601

shared hit - найдено и прочтено из shared_buffers
read - читали с файловой системы (возможно page cache системный, этого база не знает)
written - были вынуждены сами писать dirty блоки

Все эти числа измеряются блоками фиксированного размера в block_size байт. Может быть изменён только при сборке базы из исходников, потому с хорошей вероятностью можно считать что равен привычным 8кб.
(1 385 187+79 631)x8/1024 = 11 443 мегабайт

Как отобразить JSON с кириллицей на PHP?

Макс, JSON может быть только юникодом по стандарту.
Вы стандарт пытаетесь нарушить. Получаете полностью закономерные сюрпризы.

Как отобразить JSON с кириллицей на PHP?

Макс,

JSON text SHALL be encoded in UTF-8, UTF-16, or UTF-32.

https://tools.ietf.org/html/rfc7159#section-8.1
и всё. Приводите в корректную кодировку.

Преобразовать в JSON?

А что, разве у астерикса нет api или машиночитаемого формата вывода?

Как исправить ошибку raster does not exists?

как postgis поставили и, что ещё важнее - какой версии?

Как написать рекурсивную функцию на PostgreSQL?

используйте разные имена параметров функции, полей/таблиц и выходных аргументов. Чтобы обойтись без приключений.

Как быстро сортировать в большой таблице по часто изменяемому полю?

Будут читаться страницы данных, про которые visibility map не сказал что они достоверно видны всем. То есть index only scan в плане всегда может решить поднять страницу самой таблицы и проверить видимость тапла. В идеальном случае обращений к блокам таблицы не будет, в худшем - идентично index scan.

Как быстро сортировать в большой таблице по часто изменяемому полю?

все данные будут вычитаны из индекса, а это значительно сократит вам нагрузку

Баланс этот соответственно часто изменяется.

Потому сомненья большие у меня по рациональности покрывающего индекса. Очень вероятно что из-за быстро протухающего visibility map получится без разницы, есть там include или нет там его. Только с include ещё и сам индекс будет больше.