Para completar los datos: Maquina: Pentium D 3.00 GHz. Memoria: 1.74 GB PostgreSQL: 8.2. SO: Windows XP SP3. AutoVacuum: on
No se que responderles en ejecutas analyze?. Gracias Atte. Leonardo Castillo L. El 27 de abril de 2010 15:31, Jaime Casanova <[email protected]>escribió: > 2010/4/27 Alvaro Herrera <[email protected]>: > > Leonardo Castillo escribió: > > > >> Perdonen la cantidad de SQL pero es para ilustrar mejor el ejemplo. La > tabla > >> títulos posee 310.000 registros y la tabla codtit 370.000 registros. > Estan > >> relacionados por la FK "fk_cod_titulo03", ahora bien si se desea hacer > >> DELETE FROM TITULOS WHERE cod_titulo = XXXXXXX y ese cod_titulo existe > en la > >> tabla codtit, el manejador retorna error de clave foranea, lo cual está > bien > >> pues en el ON DELETE está marcado como RESTRICT, pero si el cod_titulo > no > >> está, el delete tarda 200 segundos, lo cual es un tiempo excesivo. Traté > de > >> pedir explain de la consulta y el explain pasó de 1 hora y no dió > resultado, > >> al cancerlo el pgsql me mostro esto: "SELECT 1 FROM ONLY > "public"."codtit" x > >> WHERE "cod_titulo" = $1 FOR SHARE OF x". No entiendo porque esta > situación > >> si el ya sabe que no existe registros referenciados. > > > > Hmm, normalmente esta lentitud viene porque no puede usar un índice para > > satisfacer la condición de la llave foránea; esa consulta se usa > > internamente para hacer el chequeo de esa FK. Por ejemplo puede ser que > > el índice no existe. Sin embargo en tu caso el índice está definido, > > así que debe estar pasando alguna otra cosa. Así sin más yo no veo por > > qué podría pasar esto. Los tipos de datos parecen coincidir bien. (Un > > ejercicio sencillo sería recrear las tablas y poblarlas para probar, > > pero lo dejaré para algún listero con más tiempo libre). > > > > me hablas a mi? ;) > > esto lo probe con 8.4 y la verdad me tarde mas en armar el ejemplo > (310000 y 370000 filas respectivamente) que en ejecutar la consulta: > > "Index Scan using pk_titulos on titulos (cost=0.00..8.31 rows=1 > width=6) (actual time=0.048..0.048 rows=0 loops=1)" > " Index Cond: (cod_titulo = 67777777::numeric)" > "Total runtime: 0.117 ms" > > > > Investiga qué tan rápido puede contestar consultas del tipo que muestra > > SELECT FOR SHARE, para valores de cod_titulo que existen y que no > > existen (en particular prueba con el valor que se demora 200 segundos). > > Asegúrate de probar con PREPARE y luego EXPLAIN ANALYZE EXECUTE para > > pasar el valor de $1. > > > > "Index Scan using cod_titulo on codtit x (cost=0.00..19.90 rows=4 > width=6) (actual time=0.068..0.068 rows=0 loops=1)" > " Index Cond: (cod_titulo = ($1)::numeric)" > "Total runtime: 0.179 ms" > > > "Index Scan using cod_titulo on codtit x (cost=0.00..19.90 rows=4 > width=6) (actual time=0.477..0.524 rows=3 loops=1)" > " Index Cond: (cod_titulo = ($1)::numeric)" > "Total runtime: 1.053 ms" > > > bastante rápido, ahora las preguntas que no se han hecho... que > version de postgres es esto? cuanta memoria? configuración? > ejecutas analyze? vacuum? > > -- > Atentamente, > Jaime Casanova > Soporte y capacitación de PostgreSQL > Asesoría y desarrollo de sistemas > Guayaquil - Ecuador > Cel. +59387171157 >
