RE: Bajo rendimiento en postgresql cuando se lanza un delete

> -----Mensaje original-----
> De: Francisco Manuel Quintana Trujillo
>
> Hola a todos,
>
> Hace unas semanas instalé postgresql 8.3.7 en un Windows xp sp3.
> Especificaciones de la máquina, 2 Gb de Ram, 2 discos duros
> sata de 150 Gb cada uno, procesador Pentium 4 dual core a 3.2Ghz.
>
> Un disco duro se utiliza para el sistema operativo y las
> aplicaciones, incluido el postgresql y el otro disco se
> utiliza para la base de datos la cual ocupa 105 Gb entre
> índices y datos. Lo más destacado es que existen 2 tablas que
> contienen 130 millones de registros cada una.
>

Mis recomendaciones de más importante a menos importante:

1. Tratá de tener 4 discos en RAID 10. (mejor si puedes instalar más discos)
2. Si no es posible comprar más discos, configura tus 2 discos en RAID 1
3. Llevá la base a Linux o a Windows 2003 Server

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

Se me ocurre que la fragmentación no debiera ser demasiado problemática.
Quizá afecte algo en lecturas secuenciales sobre grandes cantidades de
datos.

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

El delete debiera ser mejorable pero tendrías que mostrarnos el resultado
del explain y estructuras de observation y quality como para poder darte
alguna sugerencia.
¿No tendrás clave foráneas? Asegurate de tener índices sobre las columnas
referenciada siempre! Sino cada registro a eliminar forzará un scan
secuencial sobre la tabla referenciada a fines de verificar se cumpla la
constraint.

> Mis preguntas son:
>
> ¿Es normal?,
>

Digamos que normal no. Pero depende de la actividad del sistema, de cuantos
registros estás eliminando, cuantos índices se ven afectados, si hay claves
foráneas sobre la tabla afectada, etc.

> ¿puede ser un problema de bloqueos? ¿cómo puedo averiguar si
> la consulta no progresa?
>

Estás borrando registros. Definitivamente puede ser un problema de bloqueos
si hay otros usuarios trabajando sobre los mismos.
En postgres puedes ver los lockeos con esta consulta: select * from
pg_locks;
En Windows usa perfmon.exe para monitorear la actividad del sistema y
tendrás una idea de si está trabajando o no. Para esta consulta en
particular presta atención a la carga sobre los discos.

> ¿Qué otra solución se puede dar a la fragmentación de disco?
> ¿se puede forzar al postgresql a reservar espacio en disco?
>

Deja este tema para lo último. Dudo que sea decisivo.

> He leído las optimizaciones que se pueden realizar:
>
> Separar las distintas bases de datos en discos duros
> independientes así como sus índices, discos duros en raid,
> realizar cluster de las tablas, por el momento no son
> posibles. Además realizo vacuum cada 2 millones de inserciones.
>

Un Raid 1 no puede "no ser posible". Haz el esfuercito y no lo lamentarás.

> Agradeciendo de antemano cualquier ayuda
>
> Saludos, Oliver
>

Saludos,
Fernando.