Re: Bajo rendimiento en postgresql cuando se lanza un delete

Hola,

El problema no es tu windows... mejor dicho windows es como la atritis... se
puede vivir con ella. Cuando tu utilizas muchas llaves en tus tablas, o en
la tabla de la que quieres borrar registros tiene una llave primaria y de
ella dependen muchas tablas con muchas llaves foraneas sucede eso, que como
se soluciona.. no tengo la mas minima idea. sin embargo miro que tu delete
tiene una condicion que la hace mas lenta de lo que deberia ser.

delete from observation where observation_id not in (select
distinct(observation_id) from quality)

este es tu delete, ahi lo que estas haciendo es borrando los registros que
esten en observation que no esten en quality pero de una forma demaciado
pesada, porque?? porque por cada registro de la tabla observation estas
verificando que este no exista en quality, lo hace que dependiendo de el
numero de registros de quality y observation, el numero de comparaciones
cresca de forma espantosa.

lo que yo haria seria lo siguiente, primero obtendria los registros que si
se pueden borrar, y luego los borraria, algo como esto

select
observation_id
from
observation
except
select
observation_id
from
quality

esto te retornaria los registros que tu quieres eliminar, ahora si los
borraria asi

delete from
observation
using
(select observation_id from observation except select observation_id from
quality) as foo
where
foo.observation_id=observation.observation_id

Esperando poder bajar el tiempo de tu delete un par de horas me subscribo.

Attn.

LUIS FELIPE HERNANDEZ
PASTO - COLOMBIA

El 30 de julio de 2009 02:49, Francisco Manuel Quintana Trujillo <
fquintana(at)itccanarias(dot)org> 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.
>
>
>
> Agradeciendo de antemano cualquier ayuda
>
>
>
> Saludos, Oliver
>
>
>