[Gvsig_desarrolladores] Optimización en PostgreSQLHelper

[Leticia Riestra Ainsua]

Hola

Sí que tenemos creados los índices sobre la geometría y sí que tenemos
actualizadas las estadísticas sobre la tabla.

Por ahora, en nuestra versión, vamos a asumir el riesgo. ¿Cómo de
seriamente afecta? ¿Deja de funcionar la edición o solo se verán afectados
los zoom a toda la capa?

Gracias de todas formas.
Un saludo


El 17 de mayo de 2013 10:11, Joaquin del Cerro
<jjdelcerro.gvsig en gmail.com>escribió:

> El 16/05/13 18:10, Leticia Riestra Ainsua escribió:
> > Hola,
> >
> > Hemos modificado el método getFullEnvelopeOfField() de PostgreSQLHelper
> > para que en lugar de realizar esta consulta:
> >
> > select asbinary(extent(geometria)) from table
> >
> > cada vez que cambia la vista, sólo se haga la primera vez y que a partir
> de
> > ahí se devuelva el valor almacenado.
> >
> > Esta consulta en una tabla con 3.506.615 tuplas tarda alrededor de 7
> > segundos, y si no almacenamos el envelope, esos 7 segundos se sufren cada
> > vez que el usuario mueve la vista, o cambia el zoom.
> >
> > ¿Cual es el efecto secundario de almacenar el envelope que se obtiene de
> la
> > tabla de la base de datos en el método getFullEnvelopeOfField()
> > de PostgreSQLHelper en lugar de consultarlo cada vez que cambia la vista?
> >
> > Si creeis que no hay efectos secundarios graves, y quereis incluir el
> > código en gvSIG, os lo enviamos.
> >
>
> En principio el principal problema radicaria en que si se insertan o borran
> registros desde otros puestos y el envelope de la capa cambia no nos
> enterariamos,
> perjudicando seriamente la edicion concurrente.
>
> Lo que no termino de ver es que tarde siempre tanto. El gestor de BBDD
> deberia ser
> lo suficientemente listo para no recalcularlo si no se han hecho
> modificaciones.
> A ver si antes de la salida de la proxima version podemos echarle un
> vistazo, igual
> se podria introducir algun mecanismo para que el usuario pueda indicar si
> quiere
> que se realice esa optimizacion y como puede forzar un refresco de ese
> valor
> sin eliminar la capa y volverla a cargar.
>
> De todos modos un par de cosillas...
> ¿ Tienes creado un indice espacial sobre el campo de la geometria ?
> ¿ Actualizas las estadisticas de la tabla de vez en cuando ?
>
> En tablas tan grandes deberias tener un indice y actualizarlas de vez en
> cuando,
> dependiendo de cada cuanto tiempo segun las modificaciones que hagas sobre
> ellas.
> Por ejemplo, si la tabla se modifica varias veces al dia no estaria mal
> que incluyeses
> algun comando en el cron del sistema para actualizar las estadisticas
> diariamente, o si
> las modificaciones son esporadicas al menos una vez a la semana. La
> actualizacion
> de las estadisticas tambien puedes hacerlas automaticamante si tienes
> activado
> el autovaccum en la BBDD.
>
> Cuando manejas tablas "grandes" es critico tener los indices bien
> configurados y las
> estadisticas de las tablas actualizadas periodicamente.
>
> La otra recomendacion es que pruebes a ejecutar la consulta a mano desde
> pgadmin  o
> similar y hagas un "EXPLAIN" de ella a ver que te esta diciendo que hace y
> en funcion
> de ellos decidir que es mejor hacer.
>
> De hecho eso deberia ser una practica recomendada cuando el volumen de
> dato de la
> aplicacion crece, el provar un EXPLAIN de las consultas mas usadas, ya que
> por un
> indice mal puesto o ausente puedes tener unos rendimientos horribles.
> Con tablas grandes trabaje con SQlServer y era critico tener bien
> configurados indices
> con tablas de mas de 6 o 7 millones de registros. Con PostgreSQL no he
> trabajado con
> tablas tablas tan grandes, pero supongo que pasara lo mismo.
>
> Te recomiendo tambien que eches un vistazo a :
>
> - Section 8: Spatial Indexing
>   http://revenant.ca/www/postgis/workshop/indexing.html
>
> - 4.5. Building Indexes
>
> http://postgis.refractions.net/documentation/manual-1.3SVN/ch04.html#id2728048
>
> Bueno, a ver si cuando os quitemos de encima lo que tenemos
> podemos echarle un vistazo a la edicion en PostgreSQL con tablas
> grandes (>3 millones de registros).
> Ya nos cuentas como te va con estas cosas.
>
> Un saludo
> Joaquin
>
> > Un saludo.
> >
> >
> >
> >
> > _______________________________________________
> > gvSIG_desarrolladores mailing list
> > gvSIG_desarrolladores en listserv.gva.es
> > Para ver histórico de mensajes, editar sus preferencias de usuario o
> darse de baja en esta lista, acuda a la siguiente dirección:
> http://listserv.gva.es/cgi-bin/mailman/listinfo/gvsig_desarrolladores
>
>
> --
> --------------------------------------
> Joaquin Jose del Cerro
> Development and software arquitecture manager.
> jjdelcerro en gvsig.com
> gvSIG Association
> www.gvsig.com
> www.gvsig.org
> _______________________________________________
> gvSIG_desarrolladores mailing list
> gvSIG_desarrolladores en listserv.gva.es
> Para ver histórico de mensajes, editar sus preferencias de usuario o darse
> de baja en esta lista, acuda a la siguiente dirección:
> http://listserv.gva.es/cgi-bin/mailman/listinfo/gvsig_desarrolladores
>



-- 
Leticia Riestra Ainsua
*Laboratorio de Bases de Datos A Coruña*
*Tlfono: 981 16 70 00 Ext: 1386*
------------ próxima parte ------------
Se ha borrado un adjunto en formato HTML...
URL: http://listserv.gva.es/pipermail/gvsig_desarrolladores/attachments/20130520/46214a1c/attachment.htm