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
