Re: Ayuda con rendimiento..

From: Alvaro Herrera <alvherre(at)commandprompt(dot)com>
To: Leonardo Castillo <leonardo(at)hacer(dot)ula(dot)ve>
Cc: Mario <gonzalemario(at)gmail(dot)com>, pgsql-es-ayuda(at)postgresql(dot)org
Subject: Re: Ayuda con rendimiento..
Date: 2007-02-23 19:50:33
Message-ID: 20070223195033.GE20242@alvh.no-ip.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-es-ayuda

Leonardo Castillo escribió:

[el EXPLAIN ANALYZE, un poco arreglado para que se pueda leer]

> " -> Nested Loop (cost=47.33..6007.37 rows=22 width=25) (actual time=154.375..12087.982 rows=75369 loops=1)"
> " -> Index Scan using tipodesc01 on descript de03 (cost=0.00..8.28 rows=1 width=4) (actual time=56.178..74.196 rows=1 loops=1)"
> " Index Cond: (((tipo)::text = 'PAR'::text) AND ((tipo)::text = 'PAR'::text))"
> " -> Bitmap Heap Scan on coddesc ct03 (cost=47.33..5968.52 rows=2446 width=29) (actual time=98.164..11580.321 rows=75369 loops=1)"
> " Recheck Cond: (ct03.cod_desc = de03.codesc)"
> " -> Bitmap Index Scan on cod_desc (cost=0.00..46.72 rows=2446 width=0) (actual time=78.551..78.551 rows=75369 loops=1)"
> " Index Cond: (ct03.cod_desc = de03.codesc)"

Aca hay una estimacion muy erronea, que probablemente es la causa de que
se escoja un mal plan en todo el resto de la consulta. Fijate que en el
Bitmap Index Scan espera obtener 2446 filas, pero obtiene 75369. Esto
realmente es una deficiencia en el optimizador, porque no es capaz de
estimar correctamente la correlacion entre dos columnas; en este caso
parece ser muy alta (es decir, de la combinacion se obtienen muchas
tuplas), pero el cree que sera bastante menor, y eso causa que haga todo
el resto como nested loops en lugar de, digamos, merge joins o hash
joins.

Que yo sepa no hay ninguna manera de hacerle creer que la correlacion es
grande. Lo que yo intentaria en principio seria aumentar las
estadisticas: ALTER TABLE ... SET STATISTICS 200, para esas dos
columnas, coddesc.cod_desc y descript.codesc. Luego haz un ANALYZE de
esas dos tablas, y prueba si el plan cambia. Verifica con 100, 200,
1000, haciendo ANALYZE despues de cada una y comparando los planes.

Quizas el tener la condicion de indice repetida (tipo = 'PAR' AND tipo =
'PAR') le este causando un mareo. Prueba eliminando esa repeticion. Si
el plan cambia (basta con examinar el EXPLAIN de los dos casos para ver
si cambia o es el mismo), envia de nuevo el EXPLAIN ANALYZE.

Otra cosa que me llamo la atencion es que tienes la tabla DOCUMENT dos
veces en la consulta. Es necesario esto? Me da la impresion de que
esto fuera una consulta que antes se hacia con vistas, pero que las
vistas fueron "expandidas en linea". Por favor confirma esta hipotesis.
Es esto una migracion desde Oracle?

Para futuros envios de EXPLAIN ANALYZE, y otras cosas que sean de texto
muy ancho, por favor envialo como un archivo adjunto para no tener que
corregirlo a mano para leerlo ...

--
Alvaro Herrera http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.

In response to

Browse pgsql-es-ayuda by date

  From Date Subject
Next Message Alvaro Herrera 2007-02-23 20:00:10 Re: CALCULO DE HORAS AL DIA
Previous Message Leonardo Castillo 2007-02-23 19:44:15 Re: Ayuda con rendimiento..