Re: Auxilio Ejecuto consulta y el servicio se apaga adjunto detalle

Si claro todas las geometrias estan en la misma proyeccion

El 26 de septiembre de 2013 19:59, Felipe Guzman
<felipeguzmanv(at)gmail(dot)com>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 . <jvenegasperu(at)gmail(dot)com>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 <
>> alvherre(at)2ndquadrant(dot)com> escribió:
>>
>> Jaime Casanova escribió:
>>> > 2013/9/26 jvenegasperu . <jvenegasperu(at)gmail(dot)com>:
>>> > > 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: jvenegasperu(at)php(dot)net
>> jvenegasperu(at)gmail(dot)com
>>
>> PHP Spanish Docs translator member.
>> http://www.php.net/manual/es/index.php
>>
>
>
>
> --
> Felipe Guzman Vargas
>
>

--
José Mercedes Venegas Acevedo
cel: Mov. 949808846

mails: jvenegasperu(at)php(dot)net
jvenegasperu(at)gmail(dot)com

PHP Spanish Docs translator member.
http://www.php.net/manual/es/index.php