Re: consulta se demora mucho mas que antes

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?

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.

Quizas podrias hacer indices parciales. Cuantos valores posibles hay en
h323callorigin, y que distribucion tienen?

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