Consulta: Data WareHouse y Otros

ALguien sabe de alguna herramienta case para hacer diagramas de entidad
relacion con postgrtes ERE

de antemano gracias

Yo he hecho ingresos masivos de mas de 4 millones de registros en forma
transaccional y lo he dejado corriendo en las noches, debido al exceso de
escritura de disco, ya que la performance se degrada mucho ... y me ha
funcionado bien.

Los inserts dependiando de la cantidad o si es masivo o no , ocupan disco.
Y esto hace que la maquina se ponga lenta sobre todo en ingresos masivos
, pero en terminos generales eso es normal, sobre todo cuando realizas
una carga masiva de datos.

Al hacer esa carga de datos, lo hiciste en forma transsaccional???? como
tienes configurado en el postgresql.con lo relacionado con commit y
checkpoints

checkpoint_segments = 3 # in logfile segments, min 1, 16MB each
checkpoint_timeout = 300 # range 30-3600, in seconds
checkpoint_warning = 30 # 0 is off, in seconds
commit_delay = 0 # range 0-100000, in microseconds
commit_siblings = 5 # range 1-1000

Tus discos son SCSI

después de ese hecho hicistes un
vacuumdb -z -a ???

Saludos

> ok si, esta bien... pero me preocupa una cosa... hay ocaciones en el
> que el rendimiento de la maquina se me va abajo y no se porque razon.
> Hace poco tuve que montar una archivo de cerca de 750Mb que contiene
> lienas de instrucciones INSERT, al hacerlo el rendimiento de la
> maquina se fue abajo despues de algun tiempo, aunque cancele el
> proceso y me asegure de que no estaba corriendo ni zombie el
> rendimiento de la maquina continuó abajo, fue necesario reiniciar
> postgres y otros servicios para que recuperara el funcionamiento.
> Acerca de esto que me puedes recomendar? que otra cosa debo revisar?.
>
> En realidad agradezco mucho la ayuda que me estas dando.
>
> On Thu, 2004-06-10 at 12:17, Alvaro Herrera wrote:
>> On Thu, Jun 10, 2004 at 11:32:57AM -0500, Alejandro Casanova wrote:
>>
>> > el server tine 4 gigas de ram , y solamente tiene 19megas de
>> memoria
>> libre bajo postgresql y la memoria solo sube unpoco , reviso los
>> procesos corriendo y no hay ninguno que tome tanta memoria memoria ,
>>
>> >
>> > pregunta como minitoreo eso ? , lo monitoreo con top y ps pero no
>> me
>> muestra quien tiene esa memoria.
>>
>> Supongo que estas consciente de que en (casi?) cualquier Unix, el
>> kernel no libera la memoria de inmediato sino que queda en forma de
>> "cache" o "buffers". Ejecuta free (en un shell). Aca dice:
>>
>> $ free
>> total used free shared buffers cached
>> Mem: 450792 194240 256552 0 62008 74076
>> -/+ buffers/cache: 58156 392636
>> Swap: 0 0
>>
>>
>> observa que la cantidad de memoria libre en la practica es de 256MB,
>> _mas_ los 62 MB en buffers y los 74 MB en cache (Esos son los 392 MB
>> que salen en la fila de abajo).
>>
>> (Acabo de encender el computador, por eso sale tanta memoria libre --
>> en un par de horas mas seguramente free dira unos 4 o 10 MB ... pero
>> en buffers y cache va a haber mucha memoria)
>>
>> En resumen, no te preocupes.
>
>
> ---------------------------(end of
> broadcast)--------------------------- TIP 5: ¿Has leído nuestro
> extenso FAQ?
>
> http://www.postgresql.org/docs/faqs/FAQ.html

On Thu, Jun 10, 2004 at 02:02:50AM -0500, Roberto César Najera Núñez wrote:
> ALguien sabe de alguna herramienta case para hacer diagramas de entidad
> relacion con postgrtes ERE

DbVisualizer quizas?

Creo que habia un "gErWin", no se si realmente funcionara.

--
Alvaro Herrera (<alvherre[a]dcc.uchile.cl>)
"In Europe they call me Niklaus Wirth; in the US they call me Nickel's worth.
That's because in Europe they call me by name, and in the US by value!"

On Thu, Jun 10, 2004 at 02:01:48PM -0400, Mario Soto wrote:
> Yo he hecho ingresos masivos de mas de 4 millones de registros en forma
> transaccional y lo he dejado corriendo en las noches, debido al exceso de
> escritura de disco, ya que la performance se degrada mucho ... y me ha
> funcionado bien.

El rendimiento puede ser mucho mejor si incrementas checkpoint_segments
en una cantidad considerable (digamos dejarlo en 50). Y sort_mem
tambien (esto ultimo solo mientras dura la creacion de indices)

--
Alvaro Herrera (<alvherre[a]dcc.uchile.cl>)
"On the other flipper, one wrong move and we're Fatal Exceptions"
(T.U.X.: Term Unit X - http://www.thelinuxreview.com/TUX/)

Hola:
Tengo un problema con el rendimiento de postgres. La situacion es la
siguinete: Tengo tres tablas iguales (es necesario tenerlas en el
sistema), las tres indexadas correctamente. La unica diferencia entre
las tablas es que dos tienen integridad referencial (ON UPDATE CASCADE
ON DELETE CASCADE), cuando inserto datos en la primera de estas tabas,
las consultas salen bastante bien (me refiero rapido), pero sobre las
otras, a pesar de que tienen la misma cantidad de datos e indices, las
consultas salen mucho mas lento (3 o 4 veces mas lento que en la
primera), ahora bien, hago drop a esa table y la vuelvo a crear y al
introducirle datos responde bien. Realmente no se que sucede con esta
tabla porque cada vez que restauro una copia de seguridad o cargo datos
desde un archivo plano o script vuelve a suceder lo mismo. Podrias
ayudarme ?

Saludos

Alejandro Casanova

On Tue, Jun 15, 2004 at 03:12:14PM -0500, Alejandro Casanova wrote:
> Hola:
> Tengo un problema con el rendimiento de postgres. La situacion es la
> siguinete: Tengo tres tablas iguales (es necesario tenerlas en el
> sistema), las tres indexadas correctamente. La unica diferencia entre
> las tablas es que dos tienen integridad referencial (ON UPDATE CASCADE
> ON DELETE CASCADE), cuando inserto datos en la primera de estas tabas,
> las consultas salen bastante bien (me refiero rapido), pero sobre las
> otras, a pesar de que tienen la misma cantidad de datos e indices, las
> consultas salen mucho mas lento (3 o 4 veces mas lento que en la
> primera), ahora bien, hago drop a esa table y la vuelvo a crear y al
> introducirle datos responde bien. Realmente no se que sucede con esta
> tabla porque cada vez que restauro una copia de seguridad o cargo datos
> desde un archivo plano o script vuelve a suceder lo mismo. Podrias
> ayudarme ?

Ejecutas VACUUM regularmente?

Si es afirmativo: hay mucho movimiento de tuplas? Has probado a aplicar
REINDEX a los indices?

Realmente no es mucha la ayuda que te podemos dar si no nos das mas
informacion de la situacion (descripcion de las tablas, las llaves
foraneas, las consultas con EXPLAIN ANALYZE, si aplicas la mantencion
requerida, etc).

--
Alvaro Herrera (<alvherre[a]dcc.uchile.cl>)
"I dream about dreams about dreams", sang the nightingale
under the pale moon (Sandman)

hello

he estado preguntado y me dicen que postgresql no se comporta bien con
procesadores xeon .

que puedo hacer ?

saludos alejandro

On Tue, 2004-06-15 at 15:12, Alejandro Casanova wrote:
> Hola:
> Tengo un problema con el rendimiento de postgres. La situacion es la
> siguinete: Tengo tres tablas iguales (es necesario tenerlas en el
> sistema), las tres indexadas correctamente. La unica diferencia entre
> las tablas es que dos tienen integridad referencial (ON UPDATE CASCADE
> ON DELETE CASCADE), cuando inserto datos en la primera de estas tabas,
> las consultas salen bastante bien (me refiero rapido), pero sobre las
> otras, a pesar de que tienen la misma cantidad de datos e indices, las
> consultas salen mucho mas lento (3 o 4 veces mas lento que en la
> primera), ahora bien, hago drop a esa table y la vuelvo a crear y al
> introducirle datos responde bien. Realmente no se que sucede con esta
> tabla porque cada vez que restauro una copia de seguridad o cargo datos
> desde un archivo plano o script vuelve a suceder lo mismo. Podrias
> ayudarme ?
>
> Saludos
>
> Alejandro Casanova
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 4: No hagas 'kill -9' a postmaster

On Fri, Jun 25, 2004 at 09:17:57AM -0500, Alejandro Casanova wrote:

> he estado preguntado y me dicen que postgresql no se comporta bien con
> procesadores xeon .

En una version particular (creo que 7.3 y en las iniciales de 7.4) no
habia una definicion correcta para spinlocks (TAS).

Usando una version reciente no deberia haber problemas (7.4.3 en este
caso).

Y en caso de haberlos, ten muy presente que Postgres es un proyecto de
software libre y los desarrolladores estan muy dispuestos a enterarse de
problemas y arreglarlos. Si descubres que no funciona bien con tus
procesadores, puedes preguntarle a los desarrolladores y de seguro en un
dia o dos tendran una correccion para el problema. (De hecho esto
sucedio asi en el caso de los Xeon).

--
Alvaro Herrera (<alvherre[a]dcc.uchile.cl>)
"I would rather have GNU than GNOT." (ccchips, lwn.net/Articles/37595/)

Tengo la siguiente situación:

Hace cuatro meses estoy con un sistema en producción, que es el motor de
facturación de servicios de la empresa donde trabajo. Funciona bien y no
hemos tenido problemas asociados a Postgres como software, sin embargo si
tengo los siguientes problemas:

- Tengo ciertas consultas que demoran demasiado (sobre un universo de 6.000
registros, 15 seg aprox.). He intentado cambiar la forma de consultas, he
modificado valores en el .conf de postgres y no hay cambios relevantes

- De los resultados se obtiene estadísticas via intranet sobre los datos en
línea e históricos. Igualmente hay un tiempo de espera.

Los tiempos de espera no son críticos hoy, pero la información crece de
forma importante mes a mes y me interesaría saber si existe una forma de
mejorar trascendentalmente los tiempos.

¿Puedo implementar un Data WareHouse para las estadísticas sobre Postgresql?
¿Hay alguna configuración o forma de implementación que me haya saltado?
¿Hay alguna configuración que deba ajustar en el ODBC para Postgres 7.4?

Gracias,

Server
Dual Xeon 3.06 Ghz
1 Gb RAM
36 Gb SCSI
RedHat 8.0 (shmmax, shmall - > modificados)
PostgresQl 7.4 con valores ajustados a la memoria RAM disponible

Ejemplo:
La siguiente consulta demora 23 seg, devuelve 14.000 aprox y básicamente
consulta sobre si misma para obtener valores anteriores. Se utiliza para
presentar en la boleta de servicios el encabezado del documento con valores
"Consumo Anterior" + "Consumo Actual". Muestra todos los documentos emitidos
a la fecha y está como una vista. Cuando alguien desea emitir una boleta se
consulta sobre la vista parametrizando por el número de documento necesario
(puede ser un rango).

SELECT DISTINCT encdoc.ndoc_encdoc, encdoc.codigo_documento,
encdoc.femi_encdoc, encdoc.fven_encdoc, contratos.tfase_contrato,
tarifas.sigla_tarifa, empalmes.codigo_empalme, empalmes.loca_empalme,
ciudades.nombre_ciudad, sectores.codigo_sector, zonas.nomlargo_zona,
detcnx.serie_medidor, medidores.marca_medidor, medidores.tipo_medidor,
clientes.rut_cliente, clientes.dv_cliente,
(((btrim(clientes.nombre_cliente::text, ' '::text) || ' '::text) ||
btrim(clientes.apepat_cliente::text, ' '::text)) || ' '::text) ||
btrim(clientes.apemat::text, ' '::text) AS cliente,
(((((((btrim(ubica10.nombre_ubica10::text, ' '::text) || ' '::text) ||
btrim(empalmes.nubiinm_empalme::text, ' '::text)) || ' '::text) ||
btrim(empalmes.callenro_empalme::text, ' '::text)) || ' '::text) ||
btrim(ciudades.nombre_ciudad::text, ' '::text)) || ', '::text) ||
btrim(empalmes.loca_empalme::text, ' '::text) AS domicilio,
btrim(contratos.desdom_contrato::text, ' '::text) AS despacho,
tarcnt.potencia_tarcnt, tarcnt.constante_tarcnt,
medidores.constante_medidor, anterior.eactiva_lectura AS eactiva_anterior,
anterior.fecha_lectura AS fecha_anterior, actual.cceactiva_lectura,
actual.eactiva_lectura AS eactiva_actual, actual.fecha_lectura AS
fecha_actual, actual.ppunta_lectura, actual.pppunta_lectura,
actual.pfpunta_lectura
FROM encdoc, contratos, tarcnt, tarifas, empalmes, ciudades, sectores,
zonas, detcnx, medidores, clientes, ubica10, ( SELECT
lect2_bol.serie_medidor, lect2_bol.ndoc_encdoc, lect2_bol.codigo_documento,
lecturas.eactiva_lectura, lecturas.fecha_lectura, lecturas.ppunta_lectura,
lecturas.pppunta_lectura, lecturas.pfpunta_lectura,
lecturas.cceactiva_lectura
FROM lecturas
JOIN ( SELECT lect.serie_medidor, lect.ndoc_encdoc,
lect.codigo_documento, max(lect.fecha_lectura) AS fecha_lectura
FROM ( SELECT encdoc.ndoc_encdoc,
encdoc.codigo_documento, lecturas.serie_medidor, lecturas.fecha_lectura
FROM lecturas, encdoc
JOIN detcnx ON encdoc.codigo_contrato =
detcnx.codigo_contrato
WHERE lecturas.serie_medidor = detcnx.serie_medidor AND
lecturas.fecha_lectura <= encdoc.fproceso_encdoc AND
(lecturas.cregistro_lectura = 2::numeric OR lecturas.cregistro_lectura =
1::numeric)) lect
GROUP BY lect.serie_medidor, lect.ndoc_encdoc,
lect.codigo_documento
HAVING lect.codigo_documento <> '0000000002'::bpchar)
lect2_bol ON lect2_bol.fecha_lectura = lecturas.fecha_lectura AND
lecturas.serie_medidor = lect2_bol.serie_medidor
WHERE lecturas.cregistro_lectura = 2::numeric OR
lecturas.cregistro_lectura = 1::numeric) actual, ( SELECT
encdoc.ndoc_encdoc, encdoc.codigo_documento, blect5.fecha_lectura,
blect5.eactiva_lectura
FROM encdoc
LEFT JOIN ( SELECT blect2.codigo_documento, blect2.ndoc_encdoc,
lecturas.fecha_lectura, lecturas.eactiva_lectura
FROM ( SELECT blect3.ndoc_encdoc,
blect3.codigo_documento, blect3.serie_medidor, max(blect3.fecha_lectura) AS
fecha_lectura
FROM ( SELECT blect.ndoc_encdoc,
blect.codigo_documento, blect.serie_medidor, blect.fecha_lectura
FROM ( SELECT blect.serie_medidor,
blect.ndoc_encdoc, blect.codigo_documento, max(blect.fecha_lectura) AS
fecha_lectura
FROM ( SELECT encdoc.ndoc_encdoc,
encdoc.codigo_documento, lecturas.serie_medidor, lecturas.fecha_lectura
FROM lecturas, encdoc
JOIN detcnx ON
encdoc.codigo_contrato = detcnx.codigo_contrato
WHERE encdoc.codigo_documento =
'0000000001'::bpchar AND lecturas.serie_medidor = detcnx.serie_medidor AND
lecturas.fecha_lectura <= encdoc.fproceso_encdoc AND
(lecturas.cregistro_lectura = 2::numeric OR lecturas.cregistro_lectura =
1::numeric)) blect
GROUP BY blect.serie_medidor,
blect.ndoc_encdoc, blect.codigo_documento) blect1
JOIN ( SELECT encdoc.ndoc_encdoc,
encdoc.codigo_documento, lecturas.serie_medidor, lecturas.fecha_lectura
FROM lecturas, encdoc
JOIN detcnx ON encdoc.codigo_contrato
= detcnx.codigo_contrato
WHERE encdoc.codigo_documento =
'0000000001'::bpchar AND lecturas.serie_medidor = detcnx.serie_medidor AND
lecturas.fecha_lectura <= encdoc.fproceso_encdoc AND
(lecturas.cregistro_lectura = 2::numeric OR lecturas.cregistro_lectura =
1::numeric)) blect ON blect1.ndoc_encdoc = blect.ndoc_encdoc AND
blect1.serie_medidor = blect.serie_medidor
WHERE blect.fecha_lectura <>
blect1.fecha_lectura) blect3
GROUP BY blect3.ndoc_encdoc,
blect3.codigo_documento, blect3.serie_medidor) blect2
JOIN lecturas ON blect2.fecha_lectura = lecturas.fecha_lectura
AND blect2.serie_medidor = lecturas.serie_medidor
WHERE lecturas.cregistro_lectura = 2::numeric OR
lecturas.cregistro_lectura = 1::numeric) blect5 ON encdoc.codigo_documento =
blect5.codigo_documento AND encdoc.ndoc_encdoc = blect5.ndoc_encdoc
WHERE encdoc.codigo_documento = '0000000001'::bpchar) anterior
WHERE encdoc.ndoc_encdoc = actual.ndoc_encdoc AND encdoc.codigo_documento
= actual.codigo_documento AND encdoc.ndoc_encdoc = anterior.ndoc_encdoc AND
encdoc.codigo_documento = anterior.codigo_documento AND detcnx.serie_medidor
= medidores.serie_medidor AND encdoc.codigo_contrato =
contratos.codigo_contrato AND encdoc.codigo_contrato =
tarcnt.codigo_contrato AND encdoc.codigo_contrato = detcnx.codigo_contrato
AND tarcnt.codigo_tarifa = tarifas.codigo_tarifa AND
contratos.codigo_empalme = empalmes.codigo_empalme AND
empalmes.codigo_ciudad = ciudades.codigo_ciudad AND empalmes.codigo_sector =
sectores.codigo_sector AND empalmes.codigo_zona = zonas.codigo_zona AND
empalmes.codigo_ubica10 = ubica10.codigo_ubica10 AND encdoc.codigo_clifac =
clientes.codigo_cliente
ORDER BY encdoc.ndoc_encdoc

-----Mensaje original-----
De: pgsql-es-ayuda-owner(at)postgresql(dot)org
[mailto:pgsql-es-ayuda-owner(at)postgresql(dot)org] En nombre de Alvaro Herrera
Enviado el: Jueves, 10 de Junio de 2004 16:11
Para: Mario Soto
CC: alejandro(dot)casanova(at)telintel(dot)net; pgsql-es-ayuda(at)postgresql(dot)org
Asunto: Re: [pgsql-es-ayuda] tuning

On Thu, Jun 10, 2004 at 02:01:48PM -0400, Mario Soto wrote:
> Yo he hecho ingresos masivos de mas de 4 millones de registros en forma
> transaccional y lo he dejado corriendo en las noches, debido al exceso de
> escritura de disco, ya que la performance se degrada mucho ... y me ha
> funcionado bien.

El rendimiento puede ser mucho mejor si incrementas checkpoint_segments
en una cantidad considerable (digamos dejarlo en 50). Y sort_mem
tambien (esto ultimo solo mientras dura la creacion de indices)

--
Alvaro Herrera (<alvherre[a]dcc.uchile.cl>)
"On the other flipper, one wrong move and we're Fatal Exceptions"
(T.U.X.: Term Unit X - http://www.thelinuxreview.com/TUX/)

---------------------------(end of broadcast)---------------------------
TIP 8: explain analyze es tu amigo

On Tue, Jun 29, 2004 at 09:27:16AM -0400, Crell - Marcelo España Koock wrote:

> La siguiente consulta demora 23 seg, devuelve 14.000 aprox y básicamente
> consulta sobre si misma para obtener valores anteriores. Se utiliza para
> presentar en la boleta de servicios el encabezado del documento con valores
> "Consumo Anterior" + "Consumo Actual". Muestra todos los documentos emitidos
> a la fecha y está como una vista. Cuando alguien desea emitir una boleta se
> consulta sobre la vista parametrizando por el número de documento necesario
> (puede ser un rango).

Interesante consulta. Seria aun mas interesante ver un EXPLAIN ANALYZE
de ella. Me pregunto cuantos de esos 23 segundos se ocupan en planear
la consulta y cuanto en ejecutarla -- has intentado hacer
PREPARE/EXECUTE de ella en lugar de tener que reprocesarla cada vez?
Si el tiempo de parse/plan es muy grande puede ser buena idea ordenar
explicitamente algunos pasos. Por otra parte, como tienes algunos JOIN
explicitos quizas sea bueno quitarlos. Todo depende, naturalmente, de
como se comporte realmente.

Un truco tipicos para acelerar esta clase de consultas consiste en crear
algunas tablas de agregacion para que no tenga que calcular los totales
cada vez. No estoy seguro si es aplicable a este caso.

Supongo que leiste y seguiste las instrucciones del documento publicado
en General Bits,

http://www.varlena.com/varlena/GeneralBits/Tidbits/perf.html

--
Alvaro Herrera (<alvherre[a]dcc.uchile.cl>)
"No es bueno caminar con un hombre muerto"

Gracias.

Lo que necesitaba es jústamente lo que me indicas. Un indicio de que existe
algo por ahí que hacer.

Tengo algunas dudas de:

- cómo ver el EXPLAIN/ANALIZE
- Tablas de agregación

Veré el link que me enviaste y te comento.

-----Mensaje original-----
De: Alvaro Herrera [mailto:alvherre(at)dcc(dot)uchile(dot)cl]
Enviado el: Martes, 29 de Junio de 2004 9:43
Para: Crell - Marcelo España Koock
CC: pgsql-es-ayuda(at)postgresql(dot)org
Asunto: Re: Consulta: Data WareHouse y Otros

On Tue, Jun 29, 2004 at 09:27:16AM -0400, Crell - Marcelo España Koock
wrote:

> La siguiente consulta demora 23 seg, devuelve 14.000 aprox y básicamente
> consulta sobre si misma para obtener valores anteriores. Se utiliza para
> presentar en la boleta de servicios el encabezado del documento con
valores
> "Consumo Anterior" + "Consumo Actual". Muestra todos los documentos
emitidos
> a la fecha y está como una vista. Cuando alguien desea emitir una boleta
se
> consulta sobre la vista parametrizando por el número de documento
necesario
> (puede ser un rango).

Interesante consulta. Seria aun mas interesante ver un EXPLAIN ANALYZE
de ella. Me pregunto cuantos de esos 23 segundos se ocupan en planear
la consulta y cuanto en ejecutarla -- has intentado hacer
PREPARE/EXECUTE de ella en lugar de tener que reprocesarla cada vez?
Si el tiempo de parse/plan es muy grande puede ser buena idea ordenar
explicitamente algunos pasos. Por otra parte, como tienes algunos JOIN
explicitos quizas sea bueno quitarlos. Todo depende, naturalmente, de
como se comporte realmente.

Un truco tipicos para acelerar esta clase de consultas consiste en crear
algunas tablas de agregacion para que no tenga que calcular los totales
cada vez. No estoy seguro si es aplicable a este caso.

Supongo que leiste y seguiste las instrucciones del documento publicado
en General Bits,

http://www.varlena.com/varlena/GeneralBits/Tidbits/perf.html

--
Alvaro Herrera (<alvherre[a]dcc.uchile.cl>)
"No es bueno caminar con un hombre muerto"

Revisé el link y ya lo había visto. Ajusté los valores según lo que se
presenta ahí, cambié valores hice pruebas, devolví valores hice pruebas y
dejé lo que mejor respondía.

¿Tienes información de cómo implementar un Data Warehouse con Postgres?

Gracias,

-----Mensaje original-----
De: Alvaro Herrera [mailto:alvherre(at)dcc(dot)uchile(dot)cl]
Enviado el: Martes, 29 de Junio de 2004 9:43
Para: Crell - Marcelo España Koock
CC: pgsql-es-ayuda(at)postgresql(dot)org
Asunto: Re: Consulta: Data WareHouse y Otros

On Tue, Jun 29, 2004 at 09:27:16AM -0400, Crell - Marcelo España Koock
wrote:

> La siguiente consulta demora 23 seg, devuelve 14.000 aprox y básicamente
> consulta sobre si misma para obtener valores anteriores. Se utiliza para
> presentar en la boleta de servicios el encabezado del documento con
valores
> "Consumo Anterior" + "Consumo Actual". Muestra todos los documentos
emitidos
> a la fecha y está como una vista. Cuando alguien desea emitir una boleta
se
> consulta sobre la vista parametrizando por el número de documento
necesario
> (puede ser un rango).

Interesante consulta. Seria aun mas interesante ver un EXPLAIN ANALYZE
de ella. Me pregunto cuantos de esos 23 segundos se ocupan en planear
la consulta y cuanto en ejecutarla -- has intentado hacer
PREPARE/EXECUTE de ella en lugar de tener que reprocesarla cada vez?
Si el tiempo de parse/plan es muy grande puede ser buena idea ordenar
explicitamente algunos pasos. Por otra parte, como tienes algunos JOIN
explicitos quizas sea bueno quitarlos. Todo depende, naturalmente, de
como se comporte realmente.

Un truco tipicos para acelerar esta clase de consultas consiste en crear
algunas tablas de agregacion para que no tenga que calcular los totales
cada vez. No estoy seguro si es aplicable a este caso.

Supongo que leiste y seguiste las instrucciones del documento publicado
en General Bits,

http://www.varlena.com/varlena/GeneralBits/Tidbits/perf.html

--
Alvaro Herrera (<alvherre[a]dcc.uchile.cl>)
"No es bueno caminar con un hombre muerto"

On Tue, Jun 29, 2004 at 09:49:45AM -0400, Crell - Marcelo España Koock wrote:

> Tengo algunas dudas de:
>
> - cómo ver el EXPLAIN/ANALIZE

Simplemente ejecuta

EXPLAIN ANALYZE SELECT ... <resto de tu consulta>

Lo complicado es saber interpretar lo que arroja, y saber buscar que
corregir a partir de ahi.

> - Tablas de agregación

La idea es tener una tabla con los valores agregados (por ej. los
promedios, las sumas, los minimos o maximos, etc) de los valores que
necesites. Esto es util si usas estos valores repetidamente, porque
significa que no tienes que calcularlos una y otra vez; si son muchos o
son resultados de operaciones largas puede ser una ganancia grande de
rendimiento.

En realidad es dificil decir si te podrian servir o no sin conocer los
datos y las consultas mas en detalle. No, no lei la consulta anterior
con detencion como para decirlo.

--
Alvaro Herrera (<alvherre[a]dcc.uchile.cl>)
"El sentido de las cosas no viene de las cosas, sino de
las inteligencias que las aplican a sus problemas diarios
en busca del progreso." (Ernesto Hernández-Novich)

Gracias.

Creo que veré la utilización de tablas de agregación o bien funciones. Es
una buena idea.

Te envío el explain analize. En realidad es complejo de ver.

***********************************

Lo complicado es saber interpretar lo que arroja, y saber buscar que
corregir a partir de ahi.

> - Tablas de agregación

La idea es tener una tabla con los valores agregados (por ej. los
promedios, las sumas, los minimos o maximos, etc) de los valores que
necesites. Esto es util si usas estos valores repetidamente, porque
significa que no tienes que calcularlos una y otra vez; si son muchos o
son resultados de operaciones largas puede ser una ganancia grande de
rendimiento.

En realidad es dificil decir si te podrian servir o no sin conocer los
datos y las consultas mas en detalle. No, no lei la consulta anterior
con detencion como para decirlo.

--
Alvaro Herrera (<alvherre[a]dcc.uchile.cl>)
"El sentido de las cosas no viene de las cosas, sino de
las inteligencias que las aplican a sus problemas diarios
en busca del progreso." (Ernesto Hernández-Novich)

El mar, 29-06-2004 a las 10:15, Crell - Marcelo España Koock escribió:
> Gracias.
>
> Creo que veré la utilización de tablas de agregación o bien funciones. Es
> una buena idea.
>
> Te envío el explain analize. En realidad es complejo de ver.
>
[...]

un rápido vistazo al archivo indica que hace mucho acceso secuencial
para extraer las tuplas que cumplen con los filtros, una recomendación
es que crees índices para los campos de las tablas afectadas

ejem. La tabla lectura es accesada en forma secuencial para determinar
si cregistro_lectura = [ 1|2 ] ---> crea un índice sobre esta columna
para optimizar los accesos. Primero haz un análisis de índices con el
criterio mencionado e itera nuevamente con el explain analyze... si no
logras obtener mejores resultados entonces tienes que re-pensar tu
proceso, como dijo Alvaro, es muy buena idea manejar tablas de
agregación (por ejm. puedes actualizarlas todas las noches, o a
intervalos más regulares), luego parte interesante del proceso ya está
digerido previamente para acelerar la consulta :)

acá se han enfrentado situaciones similares con excelentes resultados.

saludos.

--
Marcelo Espinosa Alliende, mailto:marcelo(at)ubiobio(dot)cl
Depto de Servicios Computacionales
Dirección de Informática
fono: +56 41 731531, http://www.ubiobio.cl/marcelo

______________________________________________
Renovamos el Correo Yahoo!: ¡100 MB GRATIS!
Nuevos servicios, más seguridad
http://correo.yahoo.es