Ahi va: listen_addresses = '*' # what IP address(es) to listen on; max_connections = 100 shared_buffers = 41943 # min 16 or max_connections*2, 8KB each Anteriormente 1000 work_mem = 41943 # min 64, size in KB Anteriormente 1024 redirect_stderr = on
El resto de parametros estan comentados El 18 de noviembre de 2009 17:15, Jaime Casanova < [email protected]> escribió: > 2009/11/18 Fernando Hevia <[email protected]>: > > > >> -----Mensaje original----- > >> De: Cesar Erices > >> > >> Solo haz lo que te dice alvaro, es la mejor solución, VACUUM > >> mas frecuente y en especial aquellas tablas de mayor > >> movimiento, eso te reduce el problema considerablemente.. > >> > > > > Y agrego también que debierás efectuar un REINDEX en los índices sobre > > campos afectados por el update. > > > > Si ejecutas vacuum con la suficiente frecuencia el REINDEX no es tan > necesario porque el vacuum marcara el espacio en los indices tambien > como reutilizable (al menos de las tuplas muertas en la tabla). > Aun querras ejecutar REINDEX cada cierto tiempo pero no tiene porque > ser cada diani cada semana. > > Otra cosa, no te olvides de aumentar la configuracion del FSM (mapa de > espacio libre, por sus siglas en ingles) sino pones valores > correspondientes a tu instalacion aqui de nada te vale ejecutar vacuum > a cada rato. (chequea los parametros max_fsm_relations y > max_fsm_pages) > > -- > Atentamente, > Jaime Casanova > Soporte y capacitación de PostgreSQL > Asesoría y desarrollo de sistemas > Guayaquil - Ecuador > Cel. +59387171157 >
