Comments 8
Это приятное дополнение к функциональности Postgres, но использовать его нужно с умом. Если на машине с Postgres подсистема ввода-вывода является узким местом, то параллельное сканирование может только усугубить картину, ухудшив общую производительность системы.
К тому же, параллельное сканирование — это движение в сторону OLAP, и тут стоит вспомнить, что на одной машине совмещать OLAP и OLTP далеко не лучшее решение, т.к. несколько параллельных запросов аналитиков в 8 воркеров каждый создадут такую нагрузку на IO, что с SLA транзакционной части придется попрощаться
К тому же, параллельное сканирование — это движение в сторону OLAP, и тут стоит вспомнить, что на одной машине совмещать OLAP и OLTP далеко не лучшее решение, т.к. несколько параллельных запросов аналитиков в 8 воркеров каждый создадут такую нагрузку на IO, что с SLA транзакционной части придется попрощаться
+2
Создадим тестовую таблицу с полем типа INT и одним миллионом записей:
postgres=# INSERT INTO test SELECT generate_series(1,100000000);
По-моему, там чутка больше миллиона.
+2
На мой вкус, «параллельное последовательное» выглядит как взаимоисключающие параграфы, особенно для новичка. Предлагаю перевести «Parallel Seq Scan» как «параллельное упорядоченное чтение» — в противоположность «Scattered Read» — случайному чтению.
+2
Sign up to leave a comment.
PostgreSQL 9.6: Параллелизация последовательного чтения