На днях Амит Капила закоммитил патч Масахико Савады, который позволяет выполнять очистку в параллельном режиме. Сама таблица по-прежнему очищается одним (ведущим) процессом, но для очистки индексов он теперь может запускать фоновые рабочие процессы, по одному на каждый индекс. В ручном режиме это позволяет ускорить очистку больших таблиц с несколькими индексами; автоматическая очистка пока не использует эту возможность.

Ссылки по теме:


Как известно, процесс очистки таблицы состоит из нескольких фаз.

Сначала таблица сканируется и в памяти собираются ссылки на ненужные («мертвые») версии строк. Память ограничена параметром 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. Кстати, нам в нашу образовательную команду нужен человек. Чтобы умел и любил разбираться и объяснять. Где-то он есть, мы точно знаем, но пока прячется.