2009/5/8 Alvaro Herrera :
> Jaime Casanova escribió:
>
>> eso explicaria porque si lcl_maecliente solo tiene ~123000 registros
>> (que es el resultado maximo de registros que te deberia devolver la
>> consulta es eso) te esta devolviendo ~5millones de registros...
>
> Obviamente f_consumo tiene más
El día 8 de mayo de 2009 11:31, Alvaro Herrera
escribió:
> Emanuel Calvo Franco escribió:
>
>> Ernesto:
>> lo que podés hacer es que mientras se ejecute la consulta, verificar con
>> iostat y vmstat los accesos a disco. Por lo menos para tunear el work_mem
>> hasta que quepa lo mayor posible en me
Emanuel Calvo Franco escribió:
> Ernesto:
> lo que podés hacer es que mientras se ejecute la consulta, verificar con
> iostat y vmstat los accesos a disco. Por lo menos para tunear el work_mem
> hasta que quepa lo mayor posible en memoria.
Observa que si no consigues que quepa _todo_ el sort en m
Jaime Casanova escribió:
> eso explicaria porque si lcl_maecliente solo tiene ~123000 registros
> (que es el resultado maximo de registros que te deberia devolver la
> consulta es eso) te esta devolviendo ~5millones de registros...
Obviamente f_consumo tiene más de una tupla para cada valor de
lc
La respuesta es correcta, la consulta debe devolver 5 millones porque
la tabla de "movimientos" contiene periodos de consumo de esos 123k
clientes, la única llave entre ellos es el código de cliente, no
existe otra.
Ya probé varias opciones y salvo ver el tema del work_mem y quizás
subir la ram de
2009/5/7 Alvaro Herrera :
> Ernesto Quiñones escribió:
>> 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 p
El día 7 de mayo de 2009 15:35, Alvaro Herrera
escribió:
> Emanuel Calvo Franco escribió:
>> El día 7 de mayo de 2009 15:13, Ernesto Quiñones
>> escribió:
>> > uds. creen que creando un indice sobre las columns que hacen group by
>> > mejore??
>>
>> Obvia lo que te dije, porque el hash join es
Emanuel Calvo Franco escribió:
> El día 7 de mayo de 2009 15:13, Ernesto Quiñones
> escribió:
> > uds. creen que creando un indice sobre las columns que hacen group by
> > mejore??
>
> Obvia lo que te dije, porque el hash join es sobre los campos codcliente,
> por lo que significa que está toma
El día 7 de mayo de 2009 15:13, Ernesto Quiñones escribió:
> uds. creen que creando un indice sobre las columns que hacen group by mejore??
Obvia lo que te dije, porque el hash join es sobre los campos codcliente,
por lo que significa que está tomando los indices.
> saludos
>
SELECT
to_date(SU
Ernesto Quiñones wrote:
> uds. creen que creando un indice sobre las columns que hacen group by mejore??
> saludos
>
Eso no va a ayudar mucho porque tiene que ordenar de *todas* maneras a
todas las entradas.
--
Rafael Martinez,
Center for Information Technology Services
University of Oslo,
Ernesto Quiñones escribió:
> uds. creen que creando un indice sobre las columns que hacen group by mejore??
No.
--
Alvaro Herrerahttp://www.amazon.com/gp/registry/3BP7BYG9PUGI8
Thou shalt study thy libraries and strive not to reinvent them without
cause, that thy code may be shor
El día 7 de mayo de 2009 15:08, Ernesto Quiñones escribió:
> ya tienen indices ambas columnas
> gracias
>
uds. creen que creando un indice sobre las columns que hacen group by mejore??
saludos
El día 7 de mayo de 2009 13:07, Rodriguez Fernando
escribió:
> Ernesto Quiñones escribió:
>>
>> que tal amigos
>> este es el explain analyze:
>>
>> explain analyze select a.FlgCobroLlamada, a.FlgCelular,
>> a.F
Ernesto Quiñones escribió:
que tal amigos
este es el explain analyze:
explain analyze select a.FlgCobroLlamada, a.FlgCelular,
a.FlgStatusCDR, a.CodMesFactura, a.CodCiudadDestino, a.CodNpa,
a.TipLlamada, a.CodSubMotivoEstadoCliente, a.CodEstadoCliente,
a.CodPuntoVenta, a.CodCicloFacturacionClient
ya tienen indices ambas columnas
gracias
El día 7 de mayo de 2009 13:05, Emanuel Calvo Franco
escribió:
> El día 7 de mayo de 2009 13:39, Ernesto Quiñones
> escribió:
>> que tal amigos
>> este es el explain analyze:
>>
>> explain analyze select a.FlgCobroLlamada, a.FlgCelular,
>> a.FlgStatusCDR
El día 7 de mayo de 2009 13:39, Ernesto Quiñones escribió:
> que tal amigos
> este es el explain analyze:
>
> explain analyze select a.FlgCobroLlamada, a.FlgCelular,
> a.FlgStatusCDR, a.CodMesFactura, a.CodCiudadDestino, a.CodNpa,
> a.TipLlamada, a.CodSubMotivoEstadoCliente, a.CodEstadoCliente,
>
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
escribió:
> Ernesto Quiñones wrote:
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 qu
Ernesto Quiñones escribió:
> 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
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
Ernesto Quiñones wrote:
> que tal amigos
> este es el explain analyze:
> QUERY PLAN
>
que tal amigos
este es el explain analyze:
explain analyze select 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.
que tal amigos
gracias por las respuestas, antes de correr los queryas ejecuto un
vacuum full analyze sobre toda la db (proque tengo como 3 de esos que
jalan diferentes tablas)
estoy generando un explain analyze (demorará en botarme la respuesta)
para poder enviarlo y ver que esta pasando con los i
El día 6 de mayo de 2009 21:32, Ernesto Quiñones escribió:
> hola amigos, tengo 2 tablas una con 16 millones de registros y una
> tabla maestra que hace join con esta de 300,000 mil registros
> la cosa es que necesito hacer un group by y un join entre ambas tablas
> y la cosa demora mucho ( poco m
Ernesto Quiñones escribió:
hola amigos, tengo 2 tablas una con 16 millones de registros y una
tabla maestra que hace join con esta de 300,000 mil registros
la cosa es que necesito hacer un group by y un join entre ambas tablas
y la cosa demora mucho ( poco mas de una hora)
ya probe creando indic
2009/5/6 Ernesto Quiñones :
> hola amigos, tengo 2 tablas una con 16 millones de registros y una
> tabla maestra que hace join con esta de 300,000 mil registros
> la cosa es que necesito hacer un group by y un join entre ambas tablas
> y la cosa demora mucho ( poco mas de una hora)
>
> ya probe cre
hola amigos, tengo 2 tablas una con 16 millones de registros y una
tabla maestra que hace join con esta de 300,000 mil registros
la cosa es que necesito hacer un group by y un join entre ambas tablas
y la cosa demora mucho ( poco mas de una hora)
ya probe creando indices al campo que hace join ent
27 matches
Mail list logo
