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