> -----Mensaje original-----
> De: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] En nombre de
> Alvaro Herrera
> Enviado el: Lunes, 08 de Diciembre de 2008 22:21
>
> Fernando Hevia escribió:
> >
> > > >
> > > >Hay un poco de arte oscuro en esto de tunear postgres. Si te
> > > sirve de
> > > >referencia, en un servidor _dedicado_ con 4 GB de RAM, tengo la
> > > >siguiente
> > > >config:
> > > >
> > > >shared_buffers = 384MB
> > > >work_mem = 64MB
> > > >maintenance_work_mem = 132MB
> > > >effective_cache_size = 3GB
> > > >
> > > >Es un servidor que recibe pocas conexiones simultáneas pero
> > > con algunos
> > > >queries complejos (por ello el work_mem grande).
> > > >
> > >
> > > en cuanto tienes el max_connections?
> >
> > max_connections = 50
> >
> > Pero de puro gula nomás. Rara vez excedo las 15-20 conexiones.
>
> Hmm, the presente que un query complejo puede necesitar hacer
> más de un sort o hash, así que puede usar más de un área de
> "work_mem".
>
Esto es algo que estuve considerando recientemente, analizando la
conveniencia de mantener un work_mem global elevado o, mantenerlo bajo (8MB)
y setear un valor específico para la sesión justo antes de ejecutar el query
complejo. De lo indagado en los foros parece que esta última opción es la
más conservadora y garantiza mejor control sobre el consumo de memoria.
De todas maneras, por el momento este tipo de queries no se ejecutan en
paralelo por lo que estimo no tiene un impacto inmediato.
Saludos.
--
TIP 2: puedes desuscribirte de todas las listas simultáneamente
(envía "unregister TuDirecciónDeCorreo" a [EMAIL PROTECTED])
