Hola a todos hoy vuelvo a escribir con buenas noticias respecto a la consulta que simplemente apagaba el servicio de postgres
La consulta era esta: SELECT cat_distrito.distrito, 'Caja Alcantarillado'::text AS elemento, count(al_caja_geo.gid) AS cantidad from al_caja_geo JOIN cat_distrito ON st_contains(cat_distrito.the_geom,al_caja_geo.the_geom) where metropolitano = 'si' GROUP BY cat_distrito.distrito en windows 7 de 64 bits corriendo postgres 9.1 de 32 bits y postgis 1.5.5 el resultado era que se apagaba el servicio de postgres. cat_distrito contiene poligonos de alrededor de 500 puntos de extensiones de cientos de hectareas y al_caja_geo son geometrias de 5 puntos que representan un poligono cerrado de la caja de agua que esta frente a la casa. Como comente iba a migrar a una versión mas reciente de postgis por los comentarios de Jaime y Alvaro asi que de: "PostgreSQL 9.1.9, compiled by Visual C++ build 1500, 32-bit" "POSTGIS="1.5.5" GEOS="3.3.5-CAPI-1.7.5" PROJ="Rel. 4.6.1, 21 August 2008" LIBXML="2.7.8" USE_STATS" Ahora tengo lo siguiente Windows 7 de 64 bits "PostgreSQL 9.3.0, compiled by Visual C++ build 1600, 64-bit" "POSTGIS="2.1.0 r11822" GEOS="3.4.2-CAPI-1.8.2 r3924" PROJ="Rel. 4.8.0, 6 March 2012" GDAL="GDAL 1.10.0, released 2013/04/24" LIBXML="2.7.8" LIBJSON="UNKNOWN" RASTER" *y aqui si la consulta funciona de maravilla el resultado me lo muestra en tan solo 431 ms* *ademas comentar que igual me sigo conectado con ms4w de 32 bits y mi sistema no necesito cambiar ni una coma el usuario RAGI de una lista de mapserver me comento que los protocolos de comunicacion de postgres son agnosticos a al SO o arquitectura algo que no sabia asi que no hacia falta clientes a 64 bits un motivo mas para seguir apostando postgres* el resultado "02";"Caja Alcantarillado";1175 "01";"Caja Alcantarillado";26101 "14";"Caja Alcantarillado";2443 "09";"Caja Alcantarillado";28077 "13";"Caja Alcantarillado";2368 "12";"Caja Alcantarillado";462 "10";"Caja Alcantarillado";2589 "03";"Caja Alcantarillado";25284 saludos a todos El 26 de septiembre de 2013 20:02, jvenegasperu . <[email protected]>escribió: > Si claro todas las geometrias estan en la misma proyeccion > > > > El 26 de septiembre de 2013 19:59, Felipe Guzman > <[email protected]>escribió: > > Solo para salir de la duda >> ambas coberturas se encuentran en la misma proyección? >> >> >> El 26 de septiembre de 2013 18:47, jvenegasperu . <[email protected] >> > escribió: >> >> Alvaro eso es lo extraño el log que envie es de mi equipo donde tengo >>> montado todo solo me conecto con mi usuario no hay nada mas ejecutandose >>> >>> de hecho limpie todos los logs y pare el servicio y volvi a correr para >>> tener limpio el log y ver que pasa y efectivamente se cae >>> >>> Que podrian comentarme de lo siguiente: >>> Se trata de geometrias no escaladas no forman parte de una carta 1/25000 >>> o algo por el estilo se trata de coordenadas reales con distancias reales >>> la consulta intenta contar cajas de alcantarillado representados por >>> poligonos de aprox medio metro cuadrado de area dentro de cada distrito que >>> es un poligono cuya area tiene alrededor de 800 hectareas de terreno cada >>> uno. >>> >>> Digo esto porque cuando se trabaja con coordenadas escaladas por ejemplo >>> de las reales a 1 en 100 mil las consultas van muchisismo mas rapido sin >>> embargo pero en mi caso requiero las reales por el tema de decimales en las >>> mediciones en las que se pierde la precision. >>> >>> Estuve revisando como actualizar a Geos en windows pero ni idea de como >>> comenzar la compilacion sin embargo la parte buena es que postgis 2 trae >>> geos 3.4 asi que tratare de migrar a postgis 2 >>> y volvere a ejecutar la consulta haber como va. ya lo posteare aqui >>> cuando lo tenga >>> >>> Por otro lado he encontrado una solucion temporal que no seria del todo >>> cierta es decir es mas sencillo que un punto pueda estar dentro de un >>> poligono en cambio otro poligono probablemente no podria solo intersectarse >>> >>> Asi que parcialmente estoy resolviendolo asi ya que las cajas son >>> objetos pequeños les saco el centroide de cada poligono en otro campo y >>> luego ejecuto la consulta contra esta nueva geometria de tipo punto es vez >>> del poligono con lo cual tambien se reduce el tiempo de la consulta de 30 >>> segundos a 2 segundos que es lo que demoraba la consulta cuando a veces >>> funcionaba >>> >>> es decir contar los poligonos dentro de poligonos en algunas ocasiones >>> funciona en otras apaga el servicio postgres. >>> >>> Esto lo he hecho muchas veces y no ha fallado aunque siempre trabaje con >>> unos cuantos miles nunca mas de 10 mil en cambio ahora fueron 67 mil >>> >>> Asi que la consulta me quedo asi ahora: >>> >>> update al_cajas_alcantarillado_geo set the_geom2 = st_centroid(the_geom) >>> >>> >>> SELECT cat_distrito.distrito, 'Caja Alcantarillado'::text AS elemento, >>> count(al_cajas_alcantarillado_geo.gid) AS cantidad from >>> al_cajas_alcantarillado_geo >>> JOIN cat_distrito ON >>> st_contains(cat_distrito.the_geom,al_cajas_alcantarillado_geo.the_geom2) >>> >>> where metropolitano = 'si' >>> GROUP BY cat_distrito.distrito >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> El 26 de septiembre de 2013 15:44, Alvaro Herrera < >>> [email protected]> escribió: >>> >>> Jaime Casanova escribió: >>>> > 2013/9/26 jvenegasperu . <[email protected]>: >>>> > > Jaime, Alvaro gracias por responder >>>> > > >>>> > > estas son las versiones de postgres y postgis que estoy manejando >>>> > > >>>> > > "POSTGIS="1.5.5" GEOS="3.3.5-CAPI-1.7.5" PROJ="Rel. 4.6.1, 21 >>>> August 2008" >>>> > > LIBXML="2.7.8" USE_STATS" >>>> > > "PostgreSQL 9.1.9, compiled by Visual C++ build 1500, 32-bit" >>>> > > >>>> > >>>> > recientemente vimos un caso similar que pasaba por la versión de GEOS, >>>> > podrías tratar de actualizar GEOS al menos a 3.3.6 o a la versión más >>>> > reciente 3.3.8 >>>> > >>>> > Ahora, no se que tan difícil será hacer eso en windows >>>> >>>> En el git log de PostGIS se menciona un problema de memoria en >>>> ST_Contains, pero si no entiendo mal fue corregido en 1.5.4. >>>> >>>> http://trac.osgeo.org/postgis/ticket/547 >>>> >>>> https://github.com/postgis/postgis/commit/07eebf72d0df038648bc2c7f4bb7a9d6ebe282ed >>>> >>>> Pero podría ser cualquier otra cosa ... >>>> >>>> (Mis sospechas van más por creer que el OOM-killer está matando un >>>> proceso de Postgres porque algo está usando toda la memoria; no que el >>>> proceso se caiga por un bug más severo. jvenegasperu debería confirmar >>>> esto mostrando los logs.) >>>> >>>> -- >>>> Álvaro Herrera http://www.2ndQuadrant.com/ >>>> PostgreSQL Development, 24x7 Support, Training & Services >>>> >>> >>> >>> >>> -- >>> José Mercedes Venegas Acevedo >>> cel: Mov. 949808846 >>> >>> mails: [email protected] >>> [email protected] >>> >>> PHP Spanish Docs translator member. >>> http://www.php.net/manual/es/index.php >>> >> >> >> >> -- >> Felipe Guzman Vargas >> >> > > > -- > José Mercedes Venegas Acevedo > cel: Mov. 949808846 > > mails: [email protected] > [email protected] > > PHP Spanish Docs translator member. > http://www.php.net/manual/es/index.php > -- José Mercedes Venegas Acevedo cel: Mov. 949808846 mails: [email protected] [email protected] PHP Spanish Docs translator member. http://www.php.net/manual/es/index.php
