Comments 5
Сама по себе операция параллельного сканирования не имеет большого смысла, поскольку к обычным затратам на чтение страниц добавляются накладные расходы на пересылку данных от процесса к процессу.
Параллельное чтение разных участков одной таблицы само по себе может оказаться быстрее строго последовательного чтения, если подсистема ввода-вывода действительно способна выполнять запрошенные операции параллельно.
Честно говоря, не думаю. Процессам все время приходится синхронизироваться между собой, так что особого параллелизма при чтении не получится. Да и в модели стоимости считается, что чтение будет последовательным.
ну это если считать, что запрос выбирает много данных.
а если он выбирает одну запись из многих миллионов? в большинстве случаев поделить запрос на несколько подзапросов, каждый из которых читает из своей части таблицы, будет явно выгоднее, дисковая подсистема просто не способна показать максимальную скорость в один поток.
А если выбирает мало данных, то параллельное выполнение вообще не будет использоваться. Сейчас перечитал - у меня неточность: параллельное сканирование не рассматривается, если мы собираемся прочитать из таблицы меньше, чем min_parallel_table_scan_size (а не если полный размер таблицы меньше этого значения).
В целом-то вы правы, но реализация parallel seq scan вряд ли даст такой выигрыш. Другое дело - сканирование секционированных таблиц начиная с версии 11: https://commitfest.postgresql.org/16/987/ Вот там параллельно читаются целые секции и никакая синхронизация в процессе чтения не нужна.
Процессам все время приходится синхронизироваться между собой
Зависит от конкретного плана запроса.
Если идёт фильтрация для отбора записей и/или расчёт агрегатов, такие виды сканирования прекрасно распараллеливаются. Синхронизация там только по факту завершения каждой подзадачи.
Принципиально требуется только возможность назначить каждой задаче свой набор блоков для сканирования, не пересекающийся с соседями.
Запросы в PostgreSQL: 3. Последовательное сканирование