Foros del web, para los que viven de bits

Hola a todos, cómo van??

Pues resulta que estoy desarrollando un sistema de información para una empresa, la verdad no es tan complejo... la tabla en este momento que mas tiene registros es una que se llama "aforo" 12.200 registros aprox. Otra tabla tiene 11.100 aprox. Las demás al rededor de los 500, 700 registros.

En ese sistema, hay un módulo que se llama "hoja de ruta", lo que hace ese módulo es llevar el "curso" del todo proceso que se le hace a los elemento(vallas, pendones, cajas de lux, los de la tabla aforo). Para resumir y no extenderme tanto, lo que lleva ese seguimiento es:

1. El estado al producir el elemento (si ya se está produciendo o no, osea, creándolo)

2. el estado de operaciones (si ya se montó o no para mostrarlo al público, lo que muchos llámamos "pautar")

3. El reporte fotográfico, es un módulito dentro de la "hoja de ruta" donde se suben imágenes para comprobar que ya esté finalizado el proceso.

4. Pueden agragar observaciones para cada estado, osea, si produjeron, puden escribir observaciones dentro de la hoja, si pautaron pueden escribir observaciones.

Estos son los 4 procesos mas importantes de esa módulo, además de esto, maneja estados, fechas, inserciones, modificaciones, consultas, eliminaciones de casi toda la DB, puesto que esta modulo es el que integra y recopila toda la info en él.

Todo este preámbulo lo hice para que me ayuden en una cosa, ese módulo está exageradamente lento, la carga de registros, el momento de realizar una actualización, el momento de insertar un registro... Especialmente la carga... todo, todo ese módulo está relentísimo

De lo que he leido por ahí es que tengo que indexar los campos para las búsquedas, no utilizar "select * ...."

Ustedes que mas piensan que puedo hacer para optimizar las consultas y la carga de esa página.. realmente está demasiado lenta(se demora aprox. 20, 22 segundos en cargar).

Aclaro que ese módulo "hoja de ruta" no es una tabla de la DB, es un módulo que consulta en los demás tablas y hace joins entre ellas para traer los datos.

Espero me puedan ayudar y dar sugerencias...

Saludos a todos

Si el problema realmente está en la BD, indexa las consultas más lentas, puedes estudiar el plan de ejecución con un EXPLAIN ANALYZE consulta;

Hoja de ruta, es buena candidata a ser una vista!

Salu2

Ponle índices a los campos que involucres en las consultas (Olvidate del select *), no olvides de hacerles vacuum a las tablas involucradas manualmente si es que postgresql no lo hace automaticamente

Sergestux, seyko muchas gracias por sus sugerencias y recomendaciones, mañana me pondré a la tarea de optimizar ese módulo

Sergestux, la verdad no es que sepa mucho de postgres, sé hacer lo básico, insert, update, delete, select pero mas allá de eso, ni idea jeje. Me podrás explicar eso del "vacum"???

Saludos a todos

Cuando borras un registro, en realidad ese espacio fisico no se borra se marca como libre.
VACUUM se encarga de "arreglar" esta situación, puedes bajar el intervalo de autovacuum en postgresql.conf.

VACUUM ANALYZE actualiza las estadisticas de la tabla, en base a dichas estadisticas, se define el plan de ejecución de las consultas.

Más info: http://www.postgresql.org/docs/8.3/i...ql-vacuum.html

PD: No uses VACUUM FULL.

Salu2

Hola seyko, cómo vas?

Tengo muchas cosas pendientes por hacer a esa hoja de ruta Estuve leyendo el link que me dejaste, y me dices que no use VACUMM FULL, dice que es mas lento pero "compacta" y recupera mas espacio libre... Cúal es ese punto a tener en cuenta para no usarlo??

Saludos, de nuevo gracias

VACUUM FULL libera de verdad todo el espacio marcado como libre y mueve tuplas, es similar a una "defragmentación" de un disco duro, Es lento y bloquea la tabla que procesa!

Salu2

Seyko de nuevo gracias!! Me queda claro

Hola de nuevo, cómo van??

Pues bien, estos días he estado en la tarea de optimizar la "hoja_de_ruta"... Tengo unas dudas respecto a la manera de como lo estoy haciendo... No sé si es posible que me aclaren si lo estoy o no haciendo bien....

http://app.efectimedios.com/optimizar_hoja_ruta.php

En ese link verán lo que intento hacer al momento de "optmizar", aparece, la consulta original y la consulta "optmizada", en "optimizada" dejo una breve explicación de lo que intento...

Si quizás no entienden lo que hago.. por fa me preguntan para aclararle, como dije antes, lo que necesito es que me digan si lo que estoy haciendo lo ven bien o se debe hacer de otra manera....

Gracias de antemano

Saludos

prueba creando indices en las FK y en los campos que intervengan en el where, por ejemplo:
Aqui un indice en las FK y en nov_fecha se notará.

A tener en cuenta que el planificador no siempre utilizará un indice, si "cree" que es mejor no usarlo no lo hará, se puede forzar el uso de indices, pero no es muy recomendable.

Salu2

Hola seyko, gracias por tu respuesta... intentaré hacer lo que me dices... igual ya tengo en esa consulta que me muestras, dos índices, nov_fecha y nov_estado

Quiero hacerte un par de consultas:

1. Cuántos índices son recomendables crear en una tabla y/o consulta??
2. Resulta que un colega me dijo que se puede utilizar dos campos de la tabla como un índice... supón, nov_fecha y nov_subtipo hagan un solo índice...

Hacer esto es recomendable ?? Lo probé pero no vi la diferencia, al menos en tiempo, por qué y para qué se realizan este tipo de índices compuestos?, tú sabes??

Gracias man,

Saludos

Pues no esta utilizando el indice.

Tantos indices como sean necesarios. Mínimo recomiendo, campos de PK, campos de FK, y campos unicos. A partir de aqui los necesarios por ser criterios de filtrados.
Tener indices que no se utilicen es contraproducente.

Si, existen indices de varios campos.
Es recomendable? Depende!
Cada cosa en su sitio, son buenos por ejemplo para PKs de más de un campo, para temas de GIS, etc.

Para más info como siempre:
http://www.postgresql.org/docs/8.3/i...e/indexes.html

Salu2