From: | Rafael Martinez <r(dot)m(dot)guerrero(at)usit(dot)uio(dot)no> |
---|---|
To: | Ernesto Quiñones <ernestoq(at)gmail(dot)com> |
Cc: | pgsql-es-ayuda <pgsql-es-ayuda(at)postgresql(dot)org> |
Subject: | Re: querys pesados |
Date: | 2009-05-07 17:52:32 |
Message-ID: | 4A031FE0.5010609@usit.uio.no |
Views: | Whole Thread | Raw Message | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-es-ayuda |
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/
From | Date | Subject | |
---|---|---|---|
Next Message | Eduardo Arévalo | 2009-05-07 17:57:20 | Re: Hardware con postgresql....cual es mejor |
Previous Message | Alvaro Herrera | 2009-05-07 17:50:46 | Re: querys pesados |