From: | Jaime Casanova <jcasanov(at)systemguards(dot)com(dot)ec> |
---|---|
To: | Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> |
Cc: | Leonardo Castillo <leonardo(dot)castillo(at)alejandria(dot)biz>, pgsql-es-ayuda <pgsql-es-ayuda(at)postgresql(dot)org> |
Subject: | Re: Problema con borrado de tablas relacionadas. |
Date: | 2010-04-27 20:01:23 |
Message-ID: | k2r3073cc9b1004271301l16a97ea5ibc4ec701344ae8ee@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-es-ayuda |
2010/4/27 Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>:
> 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
From | Date | Subject | |
---|---|---|---|
Next Message | Leonardo Castillo | 2010-04-27 20:09:09 | Re: Problema con borrado de tablas relacionadas. |
Previous Message | Leonardo Castillo | 2010-04-27 20:01:10 | Re: Problema con borrado de tablas relacionadas. |