> -----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. -- TIP 3: Si encontraste la respuesta a tu problema, publícala, otros te lo agradecerán
