Optimización de inserción de Postgres

Question

Tengo un script que genera decenas de miles de inserciones en un db postgres a través de un ORM personalizado. Como puedes imaginar, es bastante lento. Esto se usa con fines de desarrollo para crear datos ficticios. ¿Hay una optimización simple que puedo hacer en el nivel de Postgres para hacer esto más rápido? Es el único script que se ejecuta secuencialmente y no requiere seguridad de subprocesos.

¿Puedo desactivar todas las cerraduras, controles de seguridad, disparadores, etc.? Solo estoy buscando una solución rápida y sucia que acelere en gran medida este proceso.

Gracias.

Answer 1

Si no necesita ese tipo de funcionalidad en el entorno de producción, le sugiero que desactive fsync de su configuración de PostgreSQL. Esto acelerará las inserciones dramáticamente.

Nunca apague fsync en una base de datos de producción.

Answer 2

Una cosa que puede hacer es eliminar todos los índices, hacer sus inserciones y luego volver a crear los índices.

Answer 3

¿Está enviando un lote de decenas de miles de INSERTs O ¿está enviando decenas de miles de INSERT?

Sé con Hibernate que puede agrupar todas sus declaraciones SQL y enviarlas al final en una gran porción en lugar de tomar el impuesto de la red y la sobrecarga de la base de datos para hacer miles de sentencias SQL individualmente.

Answer 4

La forma más rápida de insertar datos sería el comando COPY. Pero eso requiere un archivo plano como su entrada. Supongo que generar un archivo plano no es una opción.

No cometer con demasiada frecuencia, especialmente no ejecutar esto con el autocommit habilitado. "Decenas de miles" parece que una única confirmación al final sería la correcta.

Si puede convice su ORM para hacer uso de inserción de varias filas de Postgres' que acelerar las cosas, así

Este es un ejemplo de una inserción de múltiples filas:

 
insert into my_table (col1, col2) 
values 
(row_1_col_value1, row_1_col_value_2), 
(row_2_col_value1, row_2_col_value_2), 
(row_3_col_value1, row_3_col_value_2) 

Si no se puede generar la sintaxis anterior y está utilizando Java asegurarse de que está utilizando instrucciones por lotes en lugar de plantillas de los estados individuales (tal vez otras capas de base de datos permiten que algo similar)

Editar:

jmz 'publicación me inspiró a agregar algo:

También puede ver una mejora cuando aumenta wal_buffers a un valor mayor (p. Ej. 8MB) y checkpoint_segments (por ejemplo, 16)

Answer 5

Para insertos ese número en los cientos de miles, por lotes:

begin; 
insert1 ... 
insert2 ... 
... 
insert10k ... 
commit; 

Para insertos en los millones utilizar la copia:

COPY test (ts) FROM stdin; 
2010-11-29 22:32:01.383741-07 
2010-11-29 22:32:01.737722-07 
... 1Million rows 
\. 

asegurarse de que cualquier col utilizado como FK en otra tabla está indexado si es más que un tamaño trivial en la otra tabla.

Answer 6

Si se acaba de inicializar los datos de pruebas constantes, también se puede poner los datos de prueba en una mesa (s) de puesta en escena, a continuación, sólo copiar los contenidos de la tabla, usando

INSERT INTO... SELECT... 

que debería ser casi tan rápido como usando COPY (aunque no lo comparé), con la ventaja de que puede copiar usando solo comandos SQL, sin la molestia de configurar un archivo externo como COPY.

Answer 7

¡Intente hacer tanto como sea posible en una sola solicitud!

insert into my_table (col1, col2) 
values (
    unnest(array[row_1_col_value_1, row_2_col_value_1, row3_col_value_1]), 
    unnest(array[row_1_col_value_2, row_2_col_value_2, row_3_col_value_2)); 

Esto se asemeja a la sugerencia de @a_horse_with_no_name. La ventaja de usar unnest es: ¡puede usar parámetros de consulta que contienen matrices!

insert into my_table (col1, col2) 
values (unnest(:col_values_1), unnest(:col_values_2)); 

por el colapso de tres insert declaraciones en uno, se ahorra más del 50% del tiempo de ejecución. Y mediante el uso de parámetros de consulta con 2000 valores en un solo Insert, obtengo un factor de velocidad de 150 en mi aplicación.