RE: Bajo rendimiento en postgresql cuando se lanza un delete

> -----Mensaje original-----
> De: Francisco Manuel Quintana Trujillo
>
...

> Realicé los siguientes cambios:
>
> En la tabla "observation" eliminé temporalmente las reglas
> que estaban creadas
> -- Rule: "offering_delete_actualization ON observation"
> -- Rule: "offering_insert_actualization ON observation" No
> afecta al delete
> -- Rule: "offering_update_actualization ON observation" No
> afecta al delete
>
> Además, modifiqué la consulta
> delete from observation
> where observation_id in (select observation_id from
> observation EXCEPT select observation_id from quality);
>
> ni que decir tiene que la mejora ha sido bestial. Resultado
> del explain
>
> http://explain.depesz.com/s/llp
>
> El problema que estoy encontrando ahora es que el micro no
> está trabajando ni al 10% y en la carpeta pgsql_tmp se han
> creado unos 70 ficheros que no paran de crecer.
>

Los archivos que observas son archivos temporales que crea postgres para
poder completar el sort que conlleva la operación.
Serán eliminados al concluir la tarea.
Esto se debe a la naturaleza del nuevo query que requiere un sort de varios
millones de registros.
Son demasiados datos como para que entren en la memoria disponible para
sorts, por lo que se debe recurrir a swapeo en disco.

Puedes controlar la memoria que utiliza postgres en los sorts mediante el
parámetro work_mem.
Revisa en cuanto lo tienes seteado con:

show work_mem;

Por lo general work_mem debiera ser bajo, entre 1 y 16 MB y depende mucho
del tipo de consultas que tengas.
De todas maneras para esta consulta en particular modifica el valor antes de
ejecutar el delete:

set work_mem = 1GB;

- Ahora tira un explain sobre la consulta con el except.

- Ahora tira un explain sobre tu query original:
EXPLAIN DELETE FROM observation
WHERE observation_id NOT IN
(SELECT observation_id FROM quality)

Dependiendo de la memoria disponible, el segundo query puede llegar a ser
mucho más rápido.

Contanos como te fue.

Saludos,
Fernando.