Re: problema con query lento

estos son los indices sobre la tabla item_solicitado

CREATE INDEX idx_item_solicitado_llamado_grupo_id
ON sicp.item_solicitado
USING btree
(llamado_grupo_id);

CREATE INDEX idx_item_solicitado_producto_n5_id
ON sicp.item_solicitado
USING btree
(producto_n5_id);

CREATE INDEX idx_ver
ON sicp.item_solicitado
USING btree
(ver);

Con el parametro que le paso, solo devuelve 2 registros...

El 13 de abril de 2011 15:00, Silvio Quadri <silvioq(at)gmail(dot)com> escribió:

> El día 13 de abril de 2011 10:23, Diego Ayala <netdiego81(at)gmail(dot)com>
> escribió:
> > buenas tardes, tengo una consulta referente al uso de indices, y quisiera
> > saber como podria optimizar el select
> >
> > explain analyze SELECT llamado_grupo.id as
> > grupo_id,llamado_grupo.nro_grupo,
> llamado_grupo.abastecimiento_simultaneo,
> > llamado_grupo.contrato_abierto , item.id as item_id, item.cantidad,
> > item.cantidad_minima, item.descripcion,
> > item.estado, item.nro_linea, item.precio_promedio_catalogo,
> > item.precio_unitario, item.unidad_medida,
> > item.zona,producto_n5.id as prod_id,producto_n5.codigo,
> > item.usuario_alta
> > FROM sicp.item_solicitado item
> > INNER JOIN catalogo.producto_n5 producto_n5 on
> > item.producto_n5_id=producto_n5.id
> > INNER JOIN sicp.llamado_grupo llamado_grupo on llamado_grupo.id =
> > item.llamado_grupo_id
> > WHERE llamado_grupo.llamado_id = 127968
> > and item.ver= true
> > order by item.id
> > desc limit 10
> > offset 0
> > y el explain me devuelve esto
> >
> > "Limit (cost=0.00..3898.43 rows=10 width=128) (actual
> > time=215.455..22054.469 rows=2 loops=1)"
> > " -> Nested Loop (cost=0.00..1120408.24 rows=2874 width=128) (actual
> > time=215.453..22054.461 rows=2 loops=1)"
> > " -> Nested Loop (cost=0.00..1119596.95 rows=2874 width=116)
> > (actual time=215.436..22054.428 rows=2 loops=1)"
> > " -> Index Scan Backward using pk_item on item_solicitado
> > item (cost=0.00..200970.40 rows=2608137 width=110) (actual
> > time=0.028..6033.804 rows=2609876 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.004..0.004 rows=0
> > loops=2609876)"
> > " 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.007..0.007 rows=1
> loops=2)"
> > " Index Cond: (producto_n5.id = item.producto_n5_id)"
> > "Total runtime: 22054.633 ms"
> >
> > Son casi 22 segundos, y varia mucho, pero el promedio es de 10 a 11
> > segundos... las tablas cuentan con sus indices por cada FK que tiene.. La
> > tabla item_solicitado tiene casi 3 millones de registros, aunque no se
> como
> > afecta eso.. Lo que m llama la atencion es q el tamaño de los indices es
> > algo, tiene algo que ver eso. en la tabla sicp.item_solicitado tengo 2
> > indices, y cuyo tamaño es de 80MB cada uno, y en sicp.llamado_grupo tengo
> 1
> > indice con 20MB de tamaño, podria ser ese el prolema..???, con un reindex
> > podria solucionar esta situacion.. El servidor sobre el que corre tiene
> la
> > version 8.4.1, 64 bits, con 12 GB de RAM, y 8 cores.. y un promedio de
> 120
> > conexiones concurrentes..
> >
> > gracias por la atencion..
> >
>
> ¿Cuáles son los índices en la tabla "item"?
> ¿Y cuántos registros te devuelve la consulta (count(*))?
> Silvio
>