Re: Bajo rendimiento en postgresql cuando se lanza un delete

Francisco Manuel Quintana Trujillo escribió:

> La verdad es que todo funciona de maravillas si no tenemos en cuenta
> la fragmentación que sufre el disco en las inserciones pero que se
> resuelve con un simple defrag. El caso es que a la hora de realizar un
> select los tiempos de respuesta son más que aceptables pero no así
> cuando ejecuto un delete de este tipo
>
> delete from observation where observation_id not in (select
> distinct(observation_id) from quality) esto significa en tiempos de
> cpu 72 horas y sin solución por el momento.

¿Cual es el EXPLAIN de esta consulta? ¿Has probado reescribir la
consulta de otra forma, por ej. usando un join o un EXISTS en vez de un
subselect? ¿Hay valores NULL en observation_id en la tabla quality?
De ser así, ¿has leído respecto de las implicancias que tienen los
valores NULL en cláusulas NOT IN?

--
Alvaro Herrera http://www.amazon.com/gp/registry/5ZYLFMCVHXC
"After a quick R of TFM, all I can say is HOLY CR** THAT IS COOL! PostgreSQL was
amazing when I first started using it at 7.2, and I'm continually astounded by
learning new features and techniques made available by the continuing work of
the development team."
Berend Tober, http://archives.postgresql.org/pgsql-hackers/2007-08/msg01009.php