From: | Emanuel Calvo Franco <postgres(dot)arg(at)gmail(dot)com> |
---|---|
To: | Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> |
Cc: | Ernesto Quiñones <ernestoq(at)gmail(dot)com>, pgsql-es-ayuda <pgsql-es-ayuda(at)postgresql(dot)org> |
Subject: | Re: querys pesados |
Date: | 2009-05-08 14:37:30 |
Message-ID: | f205bb120905080737j99e543fkbfec2a502adf07fa@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-es-ayuda |
El día 8 de mayo de 2009 11:31, Alvaro Herrera
<alvherre(at)alvh(dot)no-ip(dot)org> escribió:
> Emanuel Calvo Franco escribió:
>
>> Ernesto:
>> lo que podés hacer es que mientras se ejecute la consulta, verificar con
>> iostat y vmstat los accesos a disco. Por lo menos para tunear el work_mem
>> hasta que quepa lo mayor posible en memoria.
>
> Observa que si no consigues que quepa _todo_ el sort en memoria, no
> sirve de nada agrandar work_mem, porque de todas formas tendrá que ir a
> disco. (Para saber el tamaño del sort no es necesaria ninguna
> herramienta externa, porque el EXPLAIN ANALYZE ya te dijo cuántos kB
> ocupaba el sort en disco).
>
Sort Method: external merge Disk: 1971456kB
Casi 2 gb de disco...
> Nota que puede tener sentido subir work_mem hasta 2 GB (asumiendo que el
> servidor tiene suficiente memoria) pero obviamente sólo para esa
> consulta, es decir usando SET LOCAL dentro de la transacción que ejecuta
> la consulta.
Buen punto :)
--
Emanuel Calvo Franco
Sumate al ARPUG !
( www.arpug.com.ar)
ArPUG / AOSUG Member
From | Date | Subject | |
---|---|---|---|
Next Message | Marcos Ortiz Valmaseda | 2009-05-08 14:52:33 | Re: Herramientas de Pruebas |
Previous Message | dvargas | 2009-05-08 14:34:11 | Herramientas de Pruebas |