From: | Alvaro Herrera <alvherre(at)commandprompt(dot)com> |
---|---|
To: | Leonardo Castillo <leonardo(at)hacer(dot)ula(dot)ve> |
Cc: | pgsql-es-ayuda(at)postgresql(dot)org |
Subject: | Re: Sobre uso de memoria RAM |
Date: | 2006-12-18 16:23:43 |
Message-ID: | 20061218162343.GE12526@alvh.no-ip.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-es-ayuda |
Leonardo Castillo escribió:
> Saludos Amigos listeros...
Que tal,
> Les mando explain del SQL que hace días les comenté colapsa mi servidor.
Interesante, muchas gracias.
Lo primero que me llama la atencion es la cantidad de INNER JOIN que
haces. Cuentame, que pasa si pones el parametro join_collapse_limit en
un valor mas alto? El valor por omision es 8, que es justo el tamaño de
tu consulta, y me pregunto si estará deteniendo una posible mejor
optimización de la consulta. Por favor prueba aumentando el valor a 10
o 12 o cualquier otra cosa.
Otra cosa que me llama la atencion es esto:
> -> Nested Loop (cost=12.04..3551.42 rows=1438 width=25) (actual time=42.154..336.688 rows=72270 loops=1)
> -> Index Scan using tipodesc01 on descript de02 (cost=0.00..4.25 rows=1 width=4) (actual time=0.172..0.219 rows=1 loops=1)
> Index Cond: (((tipo)::text = 'PAR'::text) AND ((tipo)::text = 'PAR'::text))
> Filter: ((descriptor)::text = 'SANTA LUCIA'::text)
> -> Bitmap Heap Scan on coddesc ct02 (cost=12.04..3525.60 rows=1438 width=35) (actual time=41.956..265.399 rows=72270 loops=1)
> Recheck Cond: (ct02.cod_desc = ("outer".codesc)::numeric)
> -> Bitmap Index Scan on cod_desc (cost=0.00..12.04 rows=1438 width=0) (actual time=38.656..38.656 rows=72270 loops=1)
> Index Cond: (ct02.cod_desc = ("outer".codesc)::numeric)
Observa que espera 1437 tuplas pero obtiene 72270. Claramente la
estimacion esta muy mala, pero creo que el problema es un grado de
correlacion entre las dos tablas que es mucho mayor que lo que el
optimizador estima. Lamentablemente no hay ninguna forma en que puedas
alterar la estimacion de correlacion. Tengo la sensacion de que aunque
se pudiera corregir el problema de arriba del collapse_limit, este
asunto te seguiria fastidiando.
Otra cosa que me llama la atencion es que tienes la tabla coddesc dos
veces en la consulta. Hay alguna razon para esto?
Hay vistas involucradas aqui? La formulacion de la consulta es muy poco
natural. Quizas deberias considerar formular vistas que encapsulen
parte de los joins de manera que la consulta sea posible de entender y
por lo tanto posible de simplificar.
Finalmente, por favor en el futuro cuando adjuntes un EXPLAIN, hazlo
como un archivo de texto separado. El que enviaste fue "corregido" por
tu cliente de correo, el cual le puso format=flowed lo cual dificulta
muchisimo la lectura del mismo (aca tuve que editarlo bastante para
poder leerlo).
--
Alvaro Herrera http://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support
From | Date | Subject | |
---|---|---|---|
Next Message | Raúl Andrés Duque Murillo | 2006-12-18 17:03:23 | Re: Trigger sujeto al tiempo |
Previous Message | Carlos Badilla | 2006-12-18 16:17:10 | No me llegan los correos |