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

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 .
<jvenegasperu(at)gmail(dot)com>escribió:

> 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
>

--
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