Потоковая вставка данных в Postgres через денормализованные таблицы. Часть 3.

Часть 1.
Часть 2.

В прошлый части я писал, что TEMP таблицы не используют Write-Ahead Log. Кроме того, такие таблицы существуют только в рамках текущей сессии. То есть они недоступны, если, например, открыть другое подключение и попытаться прочитать их.

TEMP таблицы и параллелизм

У этих таблиц есть ещё одна особенность. Postgres помечает SELECT для TEMP таблиц как PARALLEL RESTRICTED. Это значит, что при выполнении любых операций SELECT, планировщик не может распараллелить запрос, даже когда это возможно.

Что это значит на практике? Запрос, который при других условиях выполнялся бы параллельно и быстрее, не будет выполнен параллельно. Проверить это просто. Можно выполнить уже знакомый по первой части SELECT с GROUP BY на таблицах разного размера и типа (диаграмма 1).

У обычных и UNLOGGED таблиц при количестве строк от 800к – 900к меняется план выполнения с HashAggregate Seq Scan на Parallel HashAggregate Seq Scan. У TEMP таблиц такого не происходит.

Важно уточнить, что решающим фактором здесь является не количество строк, а общий размер таблицы и стоимость выполнения запроса параллельно. В моём примере именно при 800к – 900к строк таблица достигла такого объёма, при котором планировщик посчитал возможным включить параллельное выполнение.

Настройка параллелизма

Это поведение можно настроить при помощи параметров в таблице pg_settings:

min_parallel_table_scan_size = 1024 x 8 kB – минимальный размер таблицы, при котором может использоваться параллелизм;

min_parallel_index_scan_size = 64 x 8 kB – минимальный размер индекса (если есть), при котором может использоваться параллелизм;

parallel_setup_cost = 1000 – условная стоимость запуска параллельных воркеров (чем выше, тем меньше вероятность использования параллелизма);

parallel_tuple_cost 0.1– условная стоимость передачи одной строки между воркерами.

Зададим значение 0 параметраам min_parallel_table_scan_size, parallel_setup_cost и parallel_tuple_cost, назовём этот режим forced parallelism и повторим замеры на обычной таблице.

Примерно до 60–70 тысяч строк запросы с такими настройками выполняются медленнее, чем при стандартных значениях. Но при большем объёме данных параллелизм становится выгоднее. В результате время выполнения запросов сокращается почти в два раза (диаграмма 2).

Промежуточные выводы

1. Особенность TEMP таблиц не позволяет Postgres выполнять запросы на этой таблице параллельно.

2. Обычные и UNLOGGED таблицы не имеют таких ограничений. И при определённых условиях планировщик выберет параллельное выполнение.

3. Параметры базы данных можно настроить так, чтобы планировщик активнее использовал параллелизм.

Следующая часть будет завершающая на эту тему. В ней я наконец-таки расскажу про влияние индексов.