На днях Амит Капила закоммитил патч Масахико Савады, который позволяет выполнять очистку в параллельном режиме. Сама таблица по-прежнему очищается одним (ведущим) процессом, но для очистки индексов он теперь может запускать фоновые рабочие процессы, по одному на каждый индекс. В ручном режиме это позволяет ускорить очистку больших таблиц с несколькими индексами; автоматическая очистка пока не использует эту возможность.
Ссылки по теме:
Как известно, процесс очистки таблицы состоит из нескольких фаз.
Сначала таблица сканируется и в памяти собираются ссылки на ненужные («мертвые») версии строк. Память ограничена параметром maintenance_work_mem, поэтому за один раз все ссылки могут не поместиться.
Затем последовательно (так было раньше) перебираются все индексы, и из них вычищаются указатели на найденные мертвые версии строк.
Затем уже просмотренная часть таблицы сканируется еще раз и мертвые версии строк вычищаются уже из нее.
Если за один раз не удалось обработать все мертвые версии строк, то память очищается и весь процесс повторяется снова с того места, на котором мы остановились в прошлый раз.
Вся эта схема остается без изменений, но теперь индексы могут очищаться в параллель. Для этого ведущий процесс запускает несколько рабочих процессов, которые разбирают имеющиеся индексы и обрабатывают их. Один индекс обрабатывается только одним процессом. После того, когда все индексы очищены, рабочие процессы завершаются, а ведущий приступает к следующей фазе.
Для примера возьмем таблицу перелетов ticket_flights демобазы. На ней один индекс, но можно создать еще пару.
demo=# CREATE index on ticket_flights (fare_conditions);
demo=# CREATE index on ticket_flights (amount);
В параллельной обработке участвуют только те индексы, размер которых превышает значение параметра min_parallel_index_scan_size. Наши индексы подходят:
demo=# SHOW min_parallel_index_scan_size;
min_parallel_index_scan_size
------------------------------
512kB
(1 row)
demo=# SELECT pg_size_pretty(pg_relation_size(indexname::regclass))
FROM pg_indexes
WHERE tablename = 'ticket_flights';
pg_size_pretty
----------------
325 MB
187 MB
180 MB
(3 rows)
Обновим половину строк, чтобы загрузить очистку работой:
demo=# UPDATE ticket_flights SET amount = amount + 1 WHERE random() > 0.5;
UPDATE 4194262
Поехали.
demo=# VACUUM VERBOSE ticket_flights;
INFO: vacuuming "bookings.ticket_flights"
INFO: launched 2 parallel vacuum workers for index vacuuming (planned: 2)
INFO: scanned index "ticket_flights_fare_conditions_idx" to remove 4194262 row versions by parallel vacuum worker
DETAIL: CPU: user: 1.84 s, system: 0.41 s, elapsed: 11.82 s
INFO: scanned index "ticket_flights_amount_idx" to remove 4194262 row versions by parallel vacuum worker
DETAIL: CPU: user: 2.31 s, system: 0.44 s, elapsed: 12.95 s
INFO: scanned index "ticket_flights_pkey" to remove 4194262 row versions
...
INFO: "ticket_flights": found 4194262 removable, 8391852 nonremovable row versions in 104885 out of 104885 pages
DETAIL: 0 dead row versions cannot be removed yet, oldest xmin: 630
There were 0 unused item identifiers.
Skipped 0 pages due to buffer pins, 0 frozen pages.
0 pages are entirely empty.
CPU: user: 9.91 s, system: 4.40 s, elapsed: 121.40 s.
VACUUM
Тут видно, что ведущий процесс запустил два рабочих, а один индекс взял себе.
Количество рабочих процессов можно указать явно (в любом случае оно, конечно, не будет превышать max_parallel_maintenance_workers, который не превышает max_worker_processes). Явым указанием можно, в частности, воспользоваться, чтобы отключить параллелизм:
demo=# VACUUM (PARALLEL 0, VERBOSE) ticket_flights;
Надеюсь, что эта тема получит дальнейшее развитие. Таблица могла бы сканироваться параллельно несколькими процессами (это было в исходном патче Савады, но не вошло в финальный), каждый индекс также мог бы очищаться параллельно. Обязательно нужно и автоматическую очистку научить пользоваться параллелизмом.
P. S. Кстати, нам в нашу образовательную команду нужен человек. Чтобы умел и любил разбираться и объяснять. Где-то он есть, мы точно знаем, но пока прячется.
Автор: erogov
