Re: querys pesados

voy a probarlo luego, gracias por la sugerencia
el problema es que hay una herramienta tonta que genera querys de ese
tipo, por eso me preguntaba si quizas existe alguna manera de
modificando la configuracion por defecto del pgsql podria darle mayor
eficiencia a querys asi de pesados, como aumentar caches o cosas asi

saludos

El día 7 de mayo de 2009 12:24, Rafael Martinez
<r(dot)m(dot)guerrero(at)usit(dot)uio(dot)no> escribió:
> Ernesto Quiñones wrote:
>> que tal amigos
>> este es el explain analyze:
>
>> QUERY PLAN
>> -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>> GroupAggregate (cost=6793590.06..7973814.93 rows=15228708 width=106)
>> (actual time=2811295.104..5198116.245 rows=5750514 loops=1)
>> -> Sort (cost=6793590.06..6831661.83 rows=15228708 width=106)
>> (actual time=2811295.056..5119747.291 rows=15228708 loops=1)
>> Sort Key: a.flgcobrollamada, a.flgcelular, a.flgstatuscdr,
>> a.codmesfactura, a.codciudaddestino, a.codnpa, a.tipllamada,
>> a.codsubmotivoestadocliente, a.codestadocliente, a.codpuntoventa,
>> a.codciclofacturacioncliente, b.codpaisubigeocliente,
>> b.codpaisfacturacion, a.codoperador, a.codempresaut,
>> (to_date(substr((a.codhora)::text, 1, 8), 'yyyymmdd'::text)),
>> a.tipconexion, a.tipacceso
>> Sort Method: external merge Disk: 1971456kB
>> -> Hash Join (cost=6819.01..1437289.10 rows=15228708
>> width=106) (actual time=1302.791..196625.524 rows=15228708 loops=1)
>> Hash Cond: ((a.codcliente)::text =
>> (b.codcliente)::text)
>> -> Seq Scan on f_consumo a (cost=0.00..429172.08
>> rows=15228708 width=112) (actual time=4.052..65973.189 rows=15228708
>> loops=1)
>> -> Hash (cost=4555.45..4555.45 rows=123245 width=18)
>> (actual time=1298.143..1298.143 rows=123245 loops=1)
>> -> Seq Scan on lcl_maecliente b
>> (cost=0.00..4555.45 rows=123245 width=18) (actual time=14.092..953.654
>> rows=123245 loops=1)
>> Total runtime: 5217852.883 ms
>> (10 filas)
>>
>
> Hola
>
> El problema esta en que tienes que ordenar 15.228.708 de entradas por
> culpa del "group by" .
>
> Que estais intentando hacer con esta consulta? Calcular la suma total de
> a.MtoCostoValorizado y a.MtoMinutosTotalesValorizado para todas las
> entradas de f_consumo en donde
> f_consumo.codcliente=lcl_maecliente.codcliente?
>
> Si es esto lo que quereis hacer, porque no utilizais un sub-select y
> calculais la suma para los dos atributos con los datos del sub-select?
> asi os ahorrais el tener que ordenar 15.228.708 de entradas (esto es lo
> que mas tiempo ocupa)
>
> Ya contaras
> --
> Rafael Martinez, <r(dot)m(dot)guerrero(at)usit(dot)uio(dot)no>
> Center for Information Technology Services
> University of Oslo, Norway
>
> PGP Public Key: http://folk.uio.no/rafael/
>

--
Inscribete en las listas de APESOL
http://www.apesol.org/listas.php

Visita
http://www.eqsoft.net
Manuales, noticias, foros, etc.