PostgreSQL Query Optimization y el proceso de Postmaster '

Question

Actualmente estoy trabajando con una base de datos PostgreSQL derivada de wikipedia-dump más grande; Contiene unos 40 GB de datos. La base de datos se ejecuta en un servidor HP Proliant ML370 G5 con Suse Linux Enterprise Server 10; Lo estoy consultando desde mi computadora portátil a través de una red privada administrada por un simple enrutador D-Link. Asigné IPs DHCP (privadas) estáticas tanto a la computadora portátil como al servidor.

De todos modos, desde mi computadora portátil, usando pgAdmin III, envío algunos comandos / consultas SQL; algunos de estos son CREATE INDEX, DROP INDEX, DELETE, SELECT, etc. A veces envío un comando (como CREATE INDEX), vuelve, me dice que la consulta se ejecutó a la perfección, etc. Sin embargo, el proceso de administrador de correo asignado a tal El comando parece permanecer dormido en el servidor. Ahora, realmente no me importa esto, porque me digo a mí mismo que PostgreSQL mantiene un grupo de postmasters listos para procesar las consultas. Sin embargo, si este proceso consume 6 GB de memoria RAM asignada de 9.4 GB, me preocupa (y lo hace por el momento). Ahora tal vez este es un caché de datos que se guarda en la memoria [compartida] en caso de que otra consulta necesite usar los mismos datos, pero no sé.

Otra cosa me está molestando.

Tengo 2 tablas. Una es la tabla page ; Tengo un índice en su columna page_id . La otra es la tabla pagelinks que tiene la columna pl_from que no hace referencia a nada ni a una variable en la columna page.page_id ; a diferencia de la columna page_id , pl_from no tiene índice (aún). Para darle una idea de la escala de las tablas y la necesidad de encontrar una solución viable, la tabla page tiene 13.4 millones de filas (después de que eliminé las que no necesito) mientras que La tabla de enlaces de página tiene 293 millones.

Necesito ejecutar el siguiente comando para limpiar la tabla pagelinks de algunas de sus filas inútiles:

DELETE FROM pagelinks USING page WHERE pl_from NOT IN (page_id);

Básicamente, deseo eliminar la tabla pagelinks de todos los enlaces que provengan de una página que no esté en la tabla page . Incluso después de deshabilitar los bucles anidados y / o exploraciones secuenciales, el optimizador de consultas siempre me ofrece la siguiente "solución":

Nested Loop  (cost=494640.60..112115531252189.59 rows=3953377028232000 width=6)
  Join Filter: ("outer".pl_from <> "inner".page_id)"
  ->  Seq Scan on pagelinks  (cost=0.00..5889791.00 rows=293392800 width=17)
  ->  Materialize  (cost=494640.60..708341.51 rows=13474691 width=11)
        ->  Seq Scan on page  (cost=0.00..402211.91 rows=13474691 width=11)

Parece que tal tarea tardaría más de semanas en completarse; Obviamente, esto es inaceptable. Me parece que preferiría que usara el índice page_id para hacer su trabajo ... pero es un optimizador obstinado y podría estar equivocado.

Answer 1

De hecho, decidí CREAR una tabla temporal para acelerar la ejecución de consultas:

CREATE TABLE temp_to_delete AS(
    (SELECT DISTINCT pl_from FROM pagelinks) 
        EXCEPT 
    (SELECT page_id FROM page));
DELETE FROM pagelinks USING temp_to_delete 
    WHERE pagelinks.pl_from IN (temp_to_delete.pl_from);

Sorprendentemente, esta consulta se completó en aproximadamente 4 horas, mientras que la consulta inicial permaneció activa durante aproximadamente 14 horas antes de que decidiera matarla. Más específicamente, el BORRAR devuelto:

Query returned successfully: 31340904 rows affected, 4415166 ms execution time.

En cuanto a la primera parte de mi pregunta, parece que el proceso del administrador de correo de hecho mantiene cierta información en el caché; cuando otra consulta requiere información que no está en el caché y algo de memoria (RAM), el caché se vacía. Y los postmasters son, en efecto, sino un conjunto de procesos '.

También se me ha ocurrido que el gnome-system-monitor es un mito porque proporciona información incompleta y no tiene valor informativo. Es sobre todo debido a esta aplicación que he estado tan confundido últimamente; por ejemplo, no considera el uso de memoria de otros usuarios (¡como el usuario de postgres!) e incluso me dice que me quedan 12 GB de RAM cuando esto es tan falso. Por lo tanto, probé un par de monitores del sistema porque me gusta saber cómo postgreSQL está utilizando sus recursos, y parece que xosview es una herramienta válida.

Espero que esto ayude!

Answer 2

A tu segunda pregunta; puede intentar crear una nueva tabla con solo los registros que necesita con una sentencia CREATE TABLE AS; Si la nueva tabla es lo suficientemente pequeña, puede ser más rápida, pero tampoco ayuda.

Answer 3

Su proceso de administrador de correo permanecerá allí mientras la conexión con el cliente esté abierta. ¿Pgadmin cierra la conexión? No lo sé.

La memoria utilizada puede ser compartida / bloqueada (verifique la configuración) o no.

Ahora, la consulta. Para grandes operaciones de mantenimiento como esta, siéntase libre de configurar work_mem a algo grande como unos pocos GB. Parece que tienes un montón de RAM, así que úsalo.

establece work_mem en '4GB'; EXPLICAR BORRAR DE los enlaces de página DÓNDE pl_from NOT IN (SELECT page_id FROM page);

Debería secar la página de escaneo, hacer un hash y luego escanear los enlaces de página, y echar un vistazo al hash para verificar los page_ids. Debería ser bastante rápido (¡mucho más rápido que 4 horas!) Pero necesita un gran work_mem para el hash.

Pero como elimina una parte importante de su tabla, podría ser más rápido hacerlo así:

CREATE TABLE pagelinks2 AS SELECT a. * FROM pagelinks a JOIN pages b ON a.pl_from = b.page_id;

(podría usar un JOIN simple en lugar de IN)

También puede agregar un ORDEN POR LA PEDIDO en esta consulta, y su nueva tabla se ordenará muy bien en el disco para un acceso óptimo más adelante.