Re: Bajo rendimiento en postgresql cuando se lanza un delete

El 30 de julio de 2009 10:46, Edwin
Quijada<listas_quijada(at)hotmail(dot)com> escribió:
>
>
>
>> 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.
>>
>> 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.
>>
>>
>>
>> Mis preguntas son:
>>
>>
>>
>> ¿Es normal?,
>>
>>
>>
>> ¿puede ser un problema de bloqueos? ¿cómo puedo averiguar si
>> la consulta no progresa?
>>
>>
>>
>> ¿Qué otra solución se puede dar a la fragmentación de disco?
>> ¿se puede forzar al postgresql a reservar espacio en disco?
>>
>>
>> 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.
>>
>
> Tienes todo eso montado con un XP?? Vayas que eres valiente.!
> Como tienes el shered_buffers y work_men.
> Que tanto defragmentas los discos
>
> No puedes mejorar el select que no sea con una clausula not in ?
> Por que usas el distinct sabes el tiempo que eso dura , bueno suponiendo que esas tablas son las tablas de 130 millones.

Definitivamente, no tiene sentido usar el distinct.
Quizás mejorando un poco algunas configuraciones la cosa mejore, pero
si la consulta está haciendo un producto cartesiano, no hay hardware
ni sistema operativo que pueda con 130 millones al cuadrado.
Un explain vendría bastante bien para entender qué está haciendo.
Yo creo que con un índice en la tabla quality por observacion_id y sin
el distinct la cosa tendría que mejorar ... una vez perfeccionado el
query ya se puede ir pensando en los demás parámetros.

Saludos!
Silvio