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 < fquint...@itccanarias.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 > > >
