Re: consulta se demora mucho mas que antes

Alvaro Herrera wrote:

>Miguel escribió:
>
>
>
>>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)
>>where h323callorigin = 'originate'
>>and h323disconnecttime::date = '2006-03-29'::date
>>radius-# where h323callorigin = 'originate'
>>radius-# and h323disconnecttime::date = '2006-03-29'::date
>>radius-# and idproducto in (11,40,41);
>> QUERY PLAN
>>----------------------------------------------------------------------------------------------------------------------------
>>Aggregate (cost=393646.90..393646.91 rows=1 width=16)
>> -> Nested Loop (cost=0.00..393639.84 rows=1411 width=16)
>> -> Seq Scan on stopacct a (cost=0.00..382461.38 rows=1853
>>width=31)
>> 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))
>>(7 rows)
>>
>>
>
>Perdona, no me fije -- que indices tienes definidos en stopacct?
>
>
Alvaro, estos son los indices de la tabla:
Indexes:
"stopacct_pkey" PRIMARY KEY, btree (radacctid, h323calltype)
"stopacct_calledstationid" btree (calledstationid)
"stopacct_callingstationid" btree (callingstationid)
"stopacct_h323disconnectcause" btree (h323disconnectcause)
"stopacct_h323disconnecttime" btree (h323disconnecttime)
"stopacct_username" btree (username)

>Si tienes uno en h323disconnecttime, probablemente podrias invertir la
>condicion del where:
>
>where h323disconnecttime = '...' and h323callorigin = 'originate'
>
>a ver que sucede. No estoy seguro si el planner hace reordenamiento de
>estas cosas. Quizas no lo esta haciendo por algun motivo.
>
>
Invertir el orden no ayudo mucho:

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 h323disconnecttime::date = '2006-03-29'::date
radius-# and h323callorigin = 'originate'
radius-# and idproducto in (11,40,41);
QUERY PLAN
----------------------------------------------------------------------------------------------------------------------------
Aggregate (cost=393646.90..393646.91 rows=1 width=16)
-> Nested Loop (cost=0.00..393639.84 rows=1411 width=16)
-> Seq Scan on stopacct a (cost=0.00..382461.38 rows=1853
width=31)
Filter: (((h323disconnecttime)::date =
'2006-03-29'::date) AND ((h323callorigin)::text = 'originate'::text))
-> 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))
(7 rows)

>Quizas podrias hacer indices parciales. Cuantos valores posibles hay en
>h323callorigin, y que distribucion tienen?
>
>
>
el valor de h323callorigin solamente tiene dos posibilidades, answer y
originate, el teoria deberia haber uno de cada uno por cada llamadas,
pero a veces la llamada no "conecta" y entonces solamente se generar el
answer, considero que debe haber un 32% menos de originate, por ejemplo
en febrero hubieron 210977 answers y 143077 originates,

gracias
---
Miguel