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 <[email protected]> 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, <[email protected]> > 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. -- TIP 5: ¿Has leído nuestro extenso FAQ? http://www.postgresql.org/docs/faqs.FAQ.html
