Re: querys pesados

el objetivo de la consulta es poblar una tabla sumarizada, esta luego
de la consulta resulta con 5 millones de registros, voy a ver que
puedo hacer desde el lado de la consulta
gracias a todos por el apoyo
saludos

El día 7 de mayo de 2009 12:52, Rafael Martinez
<r(dot)m(dot)guerrero(at)usit(dot)uio(dot)no> escribió:
> Ernesto Quiñones wrote:
>> 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
>>
> [.......]
>>>
>>> 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)
>>>
>
> Despues de analizar la consulta mas detenidamente, no es esto lo que
> hace ..... haya el valor total de a.MtoCostoValorizado y
> a.MtoMinutosTotalesValorizado para la combinacion de atributos:
>
> 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(CAST(a.codhora as text),1,8),'yyyymmdd'),
> a.TipConexion,
> a.TipAcceso
>
> con lo que el subselect para calcular el valor total de todas las
> entradas como te sugeri no va a devolver el mismo resultado.
>
> En que contexto utilizais el resultado con varios millones de entradas?
>
> El problema es que incluso aumentando la memoria que se utiliza para
> ordenar no va ha ser sufuciente y va a utilizar como el "explain" indica
> ,el algoritmo "external merge" que utiliza casi 2GB del disco, en este caso
>
> No podeis acotar el numero de entradas a ordenar con un WHERE en el
> SELECT, o teneis que computar las sumas para 'todas' las entradas que
> cumplen f_consumo.codcliente=lcl_maecliente.codcliente en el JOIN?
>
> --
> 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.