Re: consulta se demora mucho mas que antes

Javier Aquino H. wrote:

> Comentarios al final ...
>
>
>> radius=# explain
>> radius-# select 'quemados',sum(acctsessiontime)/60 as minutos,
>> sum(roundedsessiontime)/60 as redondeados
>> radius-# from stopacct a inner join pines b on (a.username = b.pin)
>> radius-# where h323callorigin = 'originate'
>> radius-# and h323disconnecttime::date = '2006-03-29'
>> radius-# and idproducto in (11,40,41)
>> radius-# ;
>> QUERY PLAN
>> ----------------------------------------------------------------------------------------------------------------------------
>>
>> Aggregate (cost=394204.20..394204.21 rows=1 width=16)
>> -> Nested Loop (cost=0.00..394197.32 rows=1374 width=16)
>> -> Seq Scan on stopacct a (cost=0.00..383479.14 rows=1777
>> width=32)
>> Filter: (((h323callorigin)::text = 'originate'::text)
>> AND ((h323disconnecttime)::date = '2006-03-29'::date))
>> -> Index Scan using pines_pkey on pines b (cost=0.00..6.02
>> rows=1 width=13)
>> Index Cond: (("outer".username)::text = (b.pin)::text)
>> Filter: ((idproducto = 11) OR (idproducto = 40) OR
>> (idproducto = 41))
>>
>>
> No tiene por que usar índices en el filtrado siguiente:
>
> WHERE h323callorigin = 'originate'
> AND h323disconnecttime::date = '2006-03-29'
>
> La primera condición no usa indices por que no se ha indexado por esa
> columna.
> En la segunda condición haces una conversión del tipo de dato de la
> columna y por ende como el indice no es del mismo tipo pues no la usa.
>
> Lo que debes hacer es convertir el tipo de dato buscado al tipo de
> dato del campo, de este modo si usaría el índice.
>
Estas en lo correcto Javier, cambie el query de esta forma

select 'quemados',sum(acctsessiontime)/60 as minutos,
sum(roundedsessiontime)/60 as redondeados
from stopacct a inner join pines b on (a.username = b.pin)
where h323callorigin = 'originate'
and h323disconnecttime between '2006-03-29 00:00:00' and '2006-03-29
23:59:59'
and idproducto in (11,40,41)

y ahora se tarda una fraccion de segundo

radius=# explain analyze
radius-# select 'quemados',sum(acctsessiontime)/60 as minutos,
sum(roundedsessiontime)/60 as redondeados
radius-# from stopacct a inner join pines b on (a.username = b.pin)
radius-# where h323callorigin = 'originate'
radius-# and h323disconnecttime between '2006-03-29 00:00:00' and
'2006-03-29 23:59:59'
radius-# and idproducto in (11,40,41);

QUERY PLAN
---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Aggregate (cost=89896.50..89896.51 rows=1 width=16) (actual
time=136.248..136.250 rows=1 loops=1)
-> Nested Loop (cost=0.00..89855.65 rows=8168 width=16) (actual
time=0.055..121.766 rows=3568 loops=1)
-> Index Scan using stopacct_h323disconnecttime on stopacct a
(cost=0.00..25161.76 rows=10724 width=31) (actual time=0.033..33.372
rows=5624 loops=1)
Index Cond: ((h323disconnecttime >= '2006-03-29
00:00:00-06'::timestamp with time zone) AND (h323disconnecttime <=
'2006-03-29 23:59:59-06'::timestamp with time zone))
Filter: ((h323callorigin)::text = 'originate'::text)
-> Index Scan using pines_pkey on pines b (cost=0.00..6.02
rows=1 width=13) (actual time=0.009..0.010 rows=1 loops=5624)
Index Cond: (("outer".username)::text = (b.pin)::text)
Filter: ((idproducto = 11) OR (idproducto = 40) OR
(idproducto = 41))
Total runtime: 136.561 ms
(9 rows)

Hasta aqui todo perfecto, pero esta es la mejor forma de hacerlo?, el
problema es que ese rango se define seleecionado de una pagina web donde
se digita el rango y no siempre el usuario digitara el intervalo de
horas, y claro, yo podria hacerlo con javascript o algo pero antes no
era necesario, de alguna manera antes funcionaba y ahora el query planer
ha decidido hacer un seq scan (obviamente la peor decision) , afectando
el resultado final.

atte
Miguel