партицирование, при запросе, который попал в промежуток конкретной партиции, что будет происходить? копирование партиции или прям в ней оперировать будет? если прям в ней, то copy наверно только для дампа

Прям в ней

Ещё раз: партиционирование само по себе такого никогда не делает.
Более того, сам по себе PostgreSQL никогда не выполняет никаких COPY.

> копирование партиции или прям в ней оперировать будет?

Конечно, данные будут извлекаться прямо из неё (альтернатива была бы просто невыносимо тупа, Вам не кажется? ;) ).

Так, хотите сказать, что запускаемый раз в сутки дамп даёт более половины нагрузки на бд по статистике, хотя она достаточно продолжительное время нагружена на сотку?

Через htop видно что зам селекты/апдейты

Ладно, надо мониторинг уже на прод выкатить, там статистика более понятна

Откуда нам знать? Может, другие клиенты у Вас тоже используют COPY (многие API сейчас поддерживают copy protocol, по нему удобно выгружать/загружать большие recordsets).

Вот-вот. ;) А то только по pg_stat_statements Вы это не увидите.

Нет, у нас jdbc драйвер и просто большой поток данных, блобов в этой бд нет

Он готов месяца как три, не выделяют время развернуть на наши стенды и протащить в релиз и прод. Находятся "более приоритетные задачи"

Я не знаю, "умеет" jdbc использовать copy protocol или нет.
Но то, что Вы показали раньше, прямо очень похоже на запросы pg_dump. ;)

Будем надеяться

Умеет

Статистика странная

Не явно?

Явно

Крайне, потому и начал разбираться

Тогда у нас скорее всего не используется, да и в таблицы с партициями мы явно не ходим

Господа, добрый день.

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

Есть запрос

SELECT count(*) AS total
FROM (SELECT *
      FROM incoming
               JOIN sync_devices ON incoming.device_id_int = sync_devices.device_id
      WHERE incoming.demodulation_time >= '2020-07-23T16:54:37.840Z'
        AND sync_devices.batch_id = 500
      LIMIT 10000) AS query

В таблице sync_devices есть 500 записей с batch_id=500 и 3200 записей с batch_id=3200.

В таблице incoming ~18000 записей для join cо строками, содержащими batch_id=500. И больше 200000 записей для join со строками, содержащими batch_id=3200.

Планировщик использует Nested Loop для маленького джойна и Hash Join для большого джойна. В итоге, небольшое количество данных обрабатывается за 30 секунд, а в разы больший объем данных - за 700мс.

Подскажите в какую сторону копать, чтобы побороть эти тормоза на ровном месте?

В запросах дичь какая-то, выгрузка дампа в stdout