El otro día, Amit Kapila cometió un parche Masahiko Sawada, que permite la limpieza en paralelo. La tabla misma todavía se borra mediante un proceso (principal), pero para limpiar índices, ahora puede iniciar flujos de trabajo en segundo plano, uno para cada índice. En modo manual, esto le permite acelerar la limpieza de tablas grandes con múltiples índices; La limpieza automática aún no utiliza esta función.Enlaces relacionados:
Como saben , el proceso de limpieza de la mesa consta de varias fases.Primero, se escanea la tabla y los enlaces a versiones innecesarias ("muertas") de filas se recopilan en la memoria. La memoria está limitada por el parámetro maintenance_work_mem , por lo que todos los enlaces pueden no encajar a la vez.Luego, todos los índices se ordenan secuencialmente (como era antes), y se eliminan los punteros para encontrar versiones muertas de cadenas.Luego, la parte ya vista de la tabla se escanea nuevamente y las versiones muertas de las filas ya se borran de ella.Si en algún momento no fue posible procesar todas las versiones muertas de cadenas, entonces la memoria se borra y todo el proceso se repite nuevamente desde el lugar donde nos detuvimos la última vez.Todo este esquema permanece sin cambios, pero ahora los índices se pueden borrar en paralelo. Para hacer esto, el proceso principal inicia varios flujos de trabajo que analizan los índices existentes y los procesan. Un índice es procesado por un solo proceso. Después de borrar todos los índices, se completan los flujos de trabajo y el facilitador pasa a la siguiente fase.Por ejemplo, tome la ticket_flights tabla de vuelo demobase . Hay un índice en él, pero puedes crear un par más.demo=# CREATE index on ticket_flights (fare_conditions);
demo=# CREATE index on ticket_flights (amount);
Solo los índices cuyo tamaño excede el valor del parámetro min_parallel_index_scan_size están involucrados en el procesamiento paralelo . Nuestros índices son adecuados: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)
Actualice la mitad de las líneas para cargar el trabajo de limpieza:demo=# UPDATE ticket_flights SET amount = amount + 1 WHERE random() > 0.5;
UPDATE 4194262
Vamos.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
Se puede ver que el proceso líder lanzó dos trabajadores y tomó un índice.El número de procesos de trabajo se puede especificar explícitamente (en cualquier caso, por supuesto, no excederá max_parallel_maintenance_workers , que no excede max_worker_processes ). Una indicación explícita se puede utilizar, en particular, para desactivar la concurrencia:demo=# VACUUM (PARALLEL 0, VERBOSE) ticket_flights;
Espero que este tema se desarrolle más. La tabla podría escanearse en paralelo mediante varios procesos (esto estaba en el parche Savada original, pero no se incluyó en el último), cada índice también podría borrarse en paralelo. También es necesario enseñar la limpieza automática para usar el paralelismo.P. S. , . . - , , .