Tengo una tabla de base de datos muy grande en PostgresQL y una columna como "copiado". Cada nueva fila comienza sin copia y luego será replicada a otra cosa por un programa de fondo. Hay un índice parcial en esa tabla "btree (ID) WHERE replicated = 0". El programa de fondo selecciona entre 2000 entradas como máximo (LÍMITE 2000), trabaja en ellas y luego confirma los cambios en una transacción utilizando 2000 comandos sql preparados.Actualizar tabla de base de datos PostgreSQL MUY GRANDE eficientemente
Ahora el problema es que quiero darle al usuario la opción de restablecer este valor duplicado, hacer que vuelva a cero todo.
Un conjunto de tablas de actualización replicado = 0;
no es posible:
- Se necesita mucho tiempo
- Se duplica el tamaño de la tabel debido MVCC
- Se realiza en una sola transacción: Se falla o pasa a través.
En realidad, no necesito características de transacción para este caso: si el sistema deja de funcionar, procesará solo partes de él.
Varios otros problemas: haciendo un
update set replicated=0 where id >10000 and id<20000
también es malo: Se hace un recorrido secuencial por toda la mesa entera que es demasiado lento. Si no estuviese haciendo eso, aún sería lento porque sería demasiadas búsquedas.
Lo que realmente necesito es una forma de recorrer todas las filas, cambiarlas y no estar obligado a una transacción gigante.
Extrañamente, un
UPDATE table
SET replicated=0
WHERE ID in (SELECT id from table WHERE replicated= LIMIT 10000)
también es lento, aunque debe ser una buena cosa: Ir a través de la tabla de la DISK-fin ...
(Nótese que en este caso hubo también un índice que cubría este)
(un límite de actualización como MySQL no está disponible para PostgreSQL)
por cierto: El verdadero problema es más complicado y estamos hablando de una sistema embebido aquí que ya está implementado, por lo que los cambios de esquema remoto son difíciles, pero posible Desafortunadamente, es PostgresQL 7.4.
La cantidad de filas a las que me refiero es, por ejemplo, 90000000. El tamaño del databse puede ser varios dozend gigabytes.
La base de datos solo contiene 5 tablas, una es muy grande. Pero eso no es un mal diseño, porque estos cuadros integrados solo funcionan con un tipo de entidad, ¡no es un sistema ERP o algo así!
¿Alguna idea?
Esta es una muy buena idea, aunque desafortunadamente requiere un cambio de esquema (un procedimiento de actualización). Lo que realmente me gusta de este enfoque es que, de hecho, el índice parcial actual es internamente bastante similar a esta idea. Solo más flexible y manejable. – Christian