Re: tuning

Lo que dices es correcto, pero si necesitas referencia de integridad en
los datos, no puedes eliminar los indices que apuntan a las FK.
ya que podrías ingresar datos inconsistentes.

Saludos

> Ojo... al hacer inserciones masivas de cientos de registros es
> recomendable eliminar los índices y después volver a recrearlos, por que
> de lo contrario el proceso de inserción va a ser muy lento dado que el
> motor se tiene que preocupar de actualizar los índices, inserciones,
> balanceos,etc...
>
> esto ocurre en cualquier motor.
>
>
> On Thu, 2004-06-10 at 13:52, Mario Soto wrote:
>> Los inserts dependiando de la cantidad o si es masivo o no ocupan
>> disco. Y esto hace que la maquina se ponga lenta sobre todo en
>> ingresos masivos , pero en terminos generales eso es normal, sobre
>> todo cuando realizas una carga masiva de datos.
>>
>> Al hacer esa carga de datos, lo hiciste en forma transsaccional????
>> como tienes configurado en el postgresql.con lo relacionado con commit
>> y checkpoints
>>
>> checkpoint_segments = 3 # in logfile segments, min 1, 16MB
>> each checkpoint_timeout = 300 # range 30-3600, in seconds
>> checkpoint_warning = 30 # 0 is off, in seconds
>> commit_delay = 0 # range 0-100000, in microseconds
>> commit_siblings = 5 # range 1-1000
>>
>> Tus discos son SCSI
>>
>> después de ese hecho hicistes un
>> vacuumdb -z -a ???
>>
>> Saludos
>>
>>
>>
>> > ok si, esta bien... pero me preocupa una cosa... hay ocaciones en el
>> que el rendimiento de la maquina se me va abajo y no se porque
>> razon. Hace poco tuve que montar una archivo de cerca de 750Mb que
>> contiene lienas de instrucciones INSERT, al hacerlo el rendimiento
>> de la maquina se fue abajo despues de algun tiempo, aunque cancele
>> el proceso y me asegure de que no estaba corriendo ni zombie el
>> rendimiento de la maquina continuó abajo, fue necesario reiniciar
>> postgres y otros servicios para que recuperara el funcionamiento.
>> Acerca de esto que me puedes recomendar? que otra cosa debo
>> revisar?.
>> >
>> > En realidad agradezco mucho la ayuda que me estas dando.
>> >
>> > On Thu, 2004-06-10 at 12:17, Alvaro Herrera wrote:
>> >> On Thu, Jun 10, 2004 at 11:32:57AM -0500, Alejandro Casanova wrote:
>> >>
>> >> > el server tine 4 gigas de ram , y solamente tiene 19megas de
>> memoria
>> >> libre bajo postgresql y la memoria solo sube unpoco , reviso los
>> procesos corriendo y no hay ninguno que tome tanta memoria memoria
>> ,
>> >>
>> >> >
>> >> > pregunta como minitoreo eso ? , lo monitoreo con top y ps pero no
>> me
>> >> muestra quien tiene esa memoria.
>> >>
>> >> Supongo que estas consciente de que en (casi?) cualquier Unix, el
>> kernel no libera la memoria de inmediato sino que queda en forma de
>> "cache" o "buffers". Ejecuta free (en un shell). Aca dice:
>> >>
>> >> $ free
>> >> total used free shared buffers
>> cached
>> >> Mem: 450792 194240 256552 0 62008
>> 74076 -/+ buffers/cache: 58156 392636
>> >> Swap: 0 0
>> >>
>> >>
>> >> observa que la cantidad de memoria libre en la practica es de
>> 256MB, _mas_ los 62 MB en buffers y los 74 MB en cache (Esos son
>> los 392 MB que salen en la fila de abajo).
>> >>
>> >> (Acabo de encender el computador, por eso sale tanta memoria libre
>> -- en un par de horas mas seguramente free dira unos 4 o 10 MB ...
>> pero en buffers y cache va a haber mucha memoria)
>> >>
>> >> En resumen, no te preocupes.
>> >
>> >
>> > ---------------------------(end of
>> broadcast)--------------------------- TIP 5: ¿Has leído nuestro
>> extenso FAQ?
>> >
>> > http://www.postgresql.org/docs/faqs/FAQ.html
>>
>>
>>
>>
>> ---------------------------(end of
>> broadcast)--------------------------- TIP 2: puedes desuscribirte de
>> todas las listas simultáneamente
>> (envíe "unregister SuDirecciónDeCorreo" a
>> majordomo(at)postgresql(dot)org)
> --
> Marcelo Espinosa Alliende, mailto:marcelo(at)ubiobio(dot)cl
> Depto de Servicios Computacionales
> Dirección de Informática
> fono: +56 41 73154, http://www.ubiobio.cl/marcelo
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 4: No hagas 'kill -9' a postmaster