Re: problema con query lento

Amigos, una duda que no me quedo claro respecto a esto es lo siguiente,
ayer, hice pruebas en un servidor de desarrollo, y en el de produccion sobre
este query, y viendo el resultado del explain, me llamo la atencion la
diferencia de tiempo, y por sobre todo, la forma que utilizo los indices, en
produccion, solo utiliza las pk, en desarrollo, donde casi es nula la
actividad, utilizo los indices de todas las tablas, por que ese
comportamiento tan diferente, realmente tiene algo que ver la cantidad de
movimiento que existe en un servidor y otro, para que decida ejecutarse de
una y otra forma.. inclusive, hice la prueba en el servidor de produccion
durante la noche, al no haber actividad, y obtuve el mismo resultado del
explain.. les paso para el resultado de ambos, que realmente me llama mucho
la atencion, el servidor de desarrollo tiene la misma version del
postgresql, es tambien de 64 bits, pero solo tiene 4 cores y 4 GB de RAM.

EXPLAIN EN PRODUCCION, SOLO USA LAS PKs....

Limit (cost=0.00..3898.64 rows=10 width=128) (actual
time=356.290..41325.074 rows=2 loops=1)"
" -> Nested Loop (cost=0.00..1120468.40 rows=2874 width=128) (actual
time=356.288..41325.067 rows=2 loops=1)"
" -> Nested Loop (cost=0.00..1119657.11 rows=2874 width=116)
(actual time=356.268..41325.034 rows=2 loops=1)"
" -> Index Scan Backward using pk_item on item_solicitado
item (cost=0.00..200976.40 rows=2608137 width=110) (actual
time=0.051..9049.918 rows=2610986 loops=1)"
" Filter: ver"
" -> Index Scan using pk_llamado_grupo on llamado_grupo
(cost=0.00..0.34 rows=1 width=14) (actual time=0.009..0.009 rows=0
loops=2610986)"
" Index Cond: (llamado_grupo.id = item.llamado_grupo_id)"
" Filter: (llamado_grupo.llamado_id = 127968)"
" -> Index Scan using producto_n5_pkey on producto_n5
(cost=0.00..0.27 rows=1 width=20) (actual time=0.008..0.009 rows=1 loops=2)"
" Index Cond: (producto_n5.id = item.producto_n5_id)"
"Total runtime: 41325.263 ms"

EXPLAIN EN DESARROLLO, USO LOS INDICES

"Limit (cost=13514.89..13514.92 rows=10 width=128) (actual
time=44.792..44.799 rows=2 loops=1)"
" -> Sort (cost=13514.89..13522.47 rows=3031 width=128) (actual
time=44.788..44.790 rows=2 loops=1)"
" Sort Key: item.id"
" Sort Method: quicksort Memory: 25kB"
" -> Hash Join (cost=987.75..13449.39 rows=3031 width=128) (actual
time=44.742..44.770 rows=2 loops=1)"
" Hash Cond: (item.producto_n5_id = producto_n5.id)"
" -> Nested Loop (cost=0.00..12187.82 rows=3031 width=116)
(actual time=0.043..0.085 rows=2 loops=1)"
" -> Index Scan using idx_llamado_grupo_llamado_id on
llamado_grupo (cost=0.00..107.25 rows=28 width=14) (actual
time=0.024..0.030 rows=2 loops=1)"
" Index Cond: (llamado_id = 127968)"
" -> Index Scan using
idx_item_solicitado_llamado_grupo_id on item_solicitado item
(cost=0.00..430.10 rows=108 width=110) (actual time=0.015..0.019 rows=1
loops=2)"
" Index Cond: (item.llamado_grupo_id =
llamado_grupo.id)"
" Filter: item.ver"
" -> Hash (cost=647.22..647.22 rows=18522 width=20) (actual
time=42.738..42.738 rows=18522 loops=1)"
" -> Seq Scan on producto_n5 (cost=0.00..647.22
rows=18522 width=20) (actual time=0.004..21.221 rows=18522 loops=1)"
"Total runtime: 45.033 ms"

El 13 de abril de 2011 16:27, Diego Ayala <netdiego81(at)gmail(dot)com> escribió:

> Gracias x la ayuda a todos, la verdad que ha mejorado notablemente, de los
> 10 seg. q duraba en promedio, paso a 80 ms., que es un tiempo excelente, ya
> que esta consulta es utilizado muchisimo dentro de nuestro sistema. Alvaro,
> como podria saber cuando usar indice compuesto.? por que la verdad que
> siempre pense que lo correcto era un solo campo por indice..!!, y la otra
> consulta, el hecho que los demas indices tengan 80 MB de tamaño, segun lo
> veo desde el pgadmin no implica ninguna reduccion de performance en la
> planeacion para la utilizacion de esos indices..!! , PostgreSQL no tiene
> una opcion para forzar la lectura de una tabla por un indice en particular
> , que creo que Oracle que lo tiene..!!
>
> El 13 de abril de 2011 16:20, Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>escribió:
>
> Excerpts from Silvio Quadri's message of mié abr 13 17:09:19 -0300 2011:
>>
>> > Si no funciona probá también
>> > a) modificar el índice (llamado_grupo_id) por (llamado_grupo_id, id
>> desc).
>> > b) sacarle el order del final a ver si cambia el plan.
>>
>> Ojo que si le sacas el ORDER BY, la semántica del LIMIT cambia. No
>> recomiendo esto porque el conjunto de resultados es indeterminado.
>>
>> --
>> Álvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>
>>
>
>