Dado que está uniendo dos tablas grandes y no hay condiciones que puedan filtrar filas, la única estrategia de combinación eficiente será una combinación hash, y ningún índice puede ayudar con eso.
Primero habrá un escaneo secuencial de una de las tablas, a partir de la cual se construye una estructura hash, luego habrá un escaneo secuencial sobre la otra tabla, y se sondeará el hash para cada fila encontrada. ¿Cómo podría cualquier índice ayudar con eso?
Puede esperar que una operación de este tipo lleve mucho tiempo, pero hay algunas formas en las que puede acelerar la operación:
-
Eliminar todos los índices y restricciones en
tx_input1antes de que empieces. Su consulta es uno de los ejemplos en los que un índice no ayuda en absoluto, pero en realidad duele rendimiento, porque los índices tienen que ser actualizados junto con la tabla. Vuelva a crear los índices y las restricciones una vez que haya terminado conUPDATE. Dependiendo de la cantidad de índices en la tabla, puede esperar una ganancia de rendimiento decente a masiva. -
Aumente el
work_memparámetro para esta operación conSETmanda lo más alto que puedas. Cuanta más memoria pueda usar la operación hash, más rápida será. Con una tabla tan grande, es probable que aún tenga archivos temporales, pero aún puede esperar una ganancia de rendimiento decente. -
Aumentar
checkpoint_segments(omax_wal_sizedesde la versión 9.6 en adelante) a un valor alto para que haya menos puntos de control durante laUPDATEoperación. -
Asegúrese de que las estadísticas de la tabla en ambas tablas sean precisas, de modo que PostgreSQL pueda generar una buena estimación de la cantidad de cubos de hash que se crearán.
Después de la UPDATE , si afecta a una gran cantidad de filas, podría considerar ejecutar VACUUM (FULL) en tx_input1 para deshacerse de la hinchazón de la mesa resultante. Esto bloqueará la mesa durante más tiempo, así que hágalo durante una ventana de mantenimiento. Reducirá el tamaño de la tabla y, como consecuencia, acelerará los escaneos secuenciales.
