Re: Problema con borrado de tablas relacionadas.

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
<jcasanov(at)systemguards(dot)com(dot)ec>escribió:

> 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
>