[pgsql-es-ayuda] POOLL + PGBOUNCER

2013-09-26 Por tema Juan J Rosales Rodriguez 
 El servidor postgresql está conf para 600 conexiones.

12 roles de login creados.
1 base de datos.

8 nucleos 24 de ram, estamos montandole un pool de conecciones por session
con bouncer y me gustaria concer su opinion al respecto, por ejemplo como
calcularia el default_pool_size.

Como puediera configurar estos valores, quizas ya ustedes tengan
experiencias sobre este tema.

  max_client_conn = 240
  default_pool_size = 20
  reserve_pool_size = 50

Re: [pgsql-es-ayuda] POOLL + PGBOUNCER

2013-09-26 Por tema Gilberto Castillo 


>  El servidor postgresql está conf para 600 conexiones.

¿este es el valor de max_conection en postgresql.conf?

Saludos,
Gilberto Castillo
La Habana, Cuba
--- 
This message was processed by Kaspersky Mail Gateway 5.6.28/RELEASE running at 
host imx3.etecsa.cu
Visit our web-site: , 
-
Enviado a la lista de correo pgsql-es-ayuda (pgsql-es-ayuda@postgresql.org)
Para cambiar tu suscripción:
http://www.postgresql.org/mailpref/pgsql-es-ayuda

Re: [pgsql-es-ayuda] POOLL + PGBOUNCER

2013-09-26 Por tema Juan J Rosales Rodriguez 
Sip


2013/9/26 Gilberto Castillo 

>
>
> >  El servidor postgresql está conf para 600 conexiones.
>
> ¿este es el valor de max_conection en postgresql.conf?
>
> Saludos,
> Gilberto Castillo
> La Habana, Cuba
>
> ---
> This message was processed by Kaspersky Mail Gateway 5.6.28/RELEASE
> running at host imx3.etecsa.cu
> Visit our web-site: , 
>
>

Re: [pgsql-es-ayuda] POOLL + PGBOUNCER

2013-09-26 Por tema Gilberto Castillo 

> Sip
>

Pues esta mal ...si ya tienes pool lo puedas bajar hasta 20 0 30 de lo
demás se encarga el pool y postgresql tiene más memoria para utilizar.



Saludos,
Gilberto Castillo
La Habana, Cuba
--- 
This message was processed by Kaspersky Mail Gateway 5.6.28/RELEASE running at 
host imx3.etecsa.cu
Visit our web-site: , 
-
Enviado a la lista de correo pgsql-es-ayuda (pgsql-es-ayuda@postgresql.org)
Para cambiar tu suscripción:
http://www.postgresql.org/mailpref/pgsql-es-ayuda

Re: [pgsql-es-ayuda] POOLL + PGBOUNCER

2013-09-26 Por tema Juan J Rosales Rodriguez 
sip pero mi duda es como configurar el pool cuales serian las
configuraciones optimas para ese entorno


2013/9/26 Gilberto Castillo 

>
> > Sip
> >
>
> Pues esta mal ...si ya tienes pool lo puedas bajar hasta 20 0 30 de lo
> demás se encarga el pool y postgresql tiene más memoria para utilizar.
>
>
>
> Saludos,
> Gilberto Castillo
> La Habana, Cuba
>
> ---
> This message was processed by Kaspersky Mail Gateway 5.6.28/RELEASE
> running at host imx3.etecsa.cu
> Visit our web-site: , 
>
>

Re: [pgsql-es-ayuda] POOLL + PGBOUNCER

2013-09-26 Por tema Gilberto Castillo 


> sip pero mi duda es como configurar el pool cuales serian las
> configuraciones optimas para ese entorno
>

¿Te refieres a la configuración de pgbouncer?
--- 
This message was processed by Kaspersky Mail Gateway 5.6.28/RELEASE running at 
host imx3.etecsa.cu
Visit our web-site: , 
-
Enviado a la lista de correo pgsql-es-ayuda (pgsql-es-ayuda@postgresql.org)
Para cambiar tu suscripción:
http://www.postgresql.org/mailpref/pgsql-es-ayuda

Re: [pgsql-es-ayuda] POOLL + PGBOUNCER

2013-09-26 Por tema Juan J Rosales Rodriguez 
sip espeificamente  en estos 3 elementos, lo coloque de esta forma pero no
se si este correcto para el servidor y su demanda saludos y como siempre
gracias por sus respuestas

  max_client_conn= 240
  default_pool_size   = 20
  reserve_pool_size  = 50





2013/9/26 Gilberto Castillo 

>
>
> > sip pero mi duda es como configurar el pool cuales serian las
> > configuraciones optimas para ese entorno
> >
>
> ¿Te refieres a la configuración de pgbouncer?
>
> ---
> This message was processed by Kaspersky Mail Gateway 5.6.28/RELEASE
> running at host imx3.etecsa.cu
> Visit our web-site: , 
>
>

Re: [pgsql-es-ayuda] POOLL + PGBOUNCER

2013-09-26 Por tema Gilberto Castillo 


> sip espeificamente  en estos 3 elementos, lo coloque de esta forma pero no
> se si este correcto para el servidor y su demanda saludos y como siempre
> gracias por sus respuestas
>
>   max_client_conn= 240
>   default_pool_size   = 20
>   reserve_pool_size  = 50

Uso este valores:

max_client_conn = 1000
default_pool_size = 20

;reserve_pool_size = 5 (no lo usa por ahora)

Saludos,
Gilberto Castillo
La Habana, Cuba
--- 
This message was processed by Kaspersky Mail Gateway 5.6.28/RELEASE running at 
host imx3.etecsa.cu
Visit our web-site: , 
-
Enviado a la lista de correo pgsql-es-ayuda (pgsql-es-ayuda@postgresql.org)
Para cambiar tu suscripción:
http://www.postgresql.org/mailpref/pgsql-es-ayuda

[pgsql-es-ayuda] Auxilio Ejecuto consulta y el servicio se apaga adjunto detalle

2013-09-26 Por tema jvenegasperu . 
Hola a todos al ejecutar esta consulta

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_geom)
where metropolitano = 'si'
GROUP BY cat_distrito.distrito

el servicio postgres se apaga

*Esto es lo que reporta el log, trabajo en windows 7 con postgres 9.1 *

2013-09-26 11:06:36 COT LOG:  el sistema de bases de datos fue
interrumpido; última vez en funcionamiento en 2013-09-26 11:03:01 COT
2013-09-26 11:06:36 COT LOG:  el sistema de bases de datos no fue apagado
apropiadamente; se está efectuando la recuperación automática
2013-09-26 11:06:37 COT LOG:  redo comienza en 1/294415F8
2013-09-26 11:06:37 COT LOG:  registro de longitud cero en 1/29444C68
2013-09-26 11:06:37 COT LOG:  redo listo en 1/29444C28
2013-09-26 11:06:37 COT LOG:  última transacción completada al tiempo de
registro 2013-09-26 11:03:35.502-05
2013-09-26 11:06:37 COT FATAL:  el sistema de base de datos está iniciándose
2013-09-26 11:06:38 COT LOG:  lanzador de autovacuum iniciado
2013-09-26 11:06:38 COT LOG:  el sistema de bases de datos está listo para
aceptar conexiones
TopMemoryContext: 1052967360 total in 127541 blocks; 3160 free (3 chunks);
1052964200 used
  PostGIS Prepared Geometry Backend MemoryContext Hash: 4186112 total in 9
blocks; 534552 free (24 chunks); 3651560 used
  CFuncHash: 8192 total in 1 blocks; 4936 free (0 chunks); 3256 used
  TableSpace cache: 8192 total in 1 blocks; 5640 free (0 chunks); 2552 used
  Type information cache: 24576 total in 2 blocks; 14072 free (6 chunks);
10504 used
  Operator lookup cache: 24576 total in 2 blocks; 14072 free (6 chunks);
10504 used
  TopTransactionContext: 8192 total in 1 blocks; 7696 free (0 chunks); 496
used
  MessageContext: 122880 total in 4 blocks; 87760 free (14 chunks); 35120
used
  Operator class cache: 8192 total in 1 blocks; 4872 free (0 chunks); 3320
used
  smgr relation table: 8192 total in 1 blocks; 760 free (0 chunks); 7432
used
  TransactionAbortContext: 32768 total in 1 blocks; 32752 free (0 chunks);
16 used
  Portal hash: 8192 total in 1 blocks; 3912 free (0 chunks); 4280 used
  PortalMemory: 8192 total in 1 blocks; 8040 free (0 chunks); 152 used
PortalHeapMemory: 1024 total in 1 blocks; 920 free (0 chunks); 104 used
  ExecutorState: 771752000 total in 106 blocks; 96728 free (244
chunks); 771655272 used
2013-09-26 11:07:21 COT LOG:  proceso de servidor (PID 2772) fue terminado
por una excepción 0xC005
2013-09-26 11:07:21 COT HINT:  Vea el archivo «ntstatus.h» para una
descripción del valor hexadecimal.
2013-09-26 11:07:21 COT LOG:  terminando todos los otros procesos de
servidor activos
2013-09-26 11:07:21 COT WARNING:  terminando la conexión debido a una falla
en otro proceso servidor
2013-09-26 11:07:21 COT DETALLE:  Postmaster ha ordenado que este proceso
servidor cancele la transacción en curso y finalice la conexión, porque
otro proceso servidor ha terminado anormalmente y podría haber corrompido
la memoria compartida.
2013-09-26 11:07:21 COT HINT:  Dentro de un momento debería poder
reconectarse y repetir la consulta.
2013-09-26 11:07:21 COT LOG:  todos los procesos fueron terminados;
reinicializando


Tengo estos valores en la configuracion del postgres pongo solo los que
cambie el resto to por defecto

shared_buffers = 128MB# min 128kB
#temp_buffers = 8MB# min 800kB
work_mem = 14MB# min 64kB
maintenance_work_mem = 64MB# min 1MB

ojala puedan ayudarme un saludo







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

mails: jvenegasp...@php.net
  jvenegasp...@gmail.com

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

Re: [pgsql-es-ayuda] Auxilio Ejecuto consulta y el servicio se apaga adjunto detalle

2013-09-26 Por tema Jaime Casanova 
2013/9/26 jvenegasperu . :
>
> el servicio postgres se apaga
>
> Esto es lo que reporta el log, trabajo en windows 7 con postgres 9.1
>

Saludos,

ese error es "access violation", y por los mensajes en el log puede
provenir de postgis.
puedes mostrar las versiones exactas de postgres y postgis?

select version();

select postgis_full_version();

la idea ahi es verificar que tengas hasta el ultimo release de
seguridad de cada version de cada uno de los productos involucrados.
me parece recordar que el GEOS causaba un problema.

-- 
Jaime Casanova www.2ndQuadrant.com
Professional PostgreSQL: Soporte 24x7 y capacitación
Phone: +593 4 5107566 Cell: +593 987171157

-
Enviado a la lista de correo pgsql-es-ayuda (pgsql-es-ayuda@postgresql.org)
Para cambiar tu suscripción:
http://www.postgresql.org/mailpref/pgsql-es-ayuda

Re: [pgsql-es-ayuda] Auxilio Ejecuto consulta y el servicio se apaga adjunto detalle

2013-09-26 Por tema Alvaro Herrera 
Jaime Casanova escribió:
> 2013/9/26 jvenegasperu . :
> >
> > el servicio postgres se apaga
> >
> > Esto es lo que reporta el log, trabajo en windows 7 con postgres 9.1
> 
> Saludos,
> 
> ese error es "access violation", y por los mensajes en el log puede
> provenir de postgis.
> puedes mostrar las versiones exactas de postgres y postgis?

La cantidad de memoria reportada es muy grande.  Hay como 1 GB en
TopMemoryContext y otros 700 MB en un contexto del ejecutor.  Es muy
posible que haya una fuga de memoria en PostGIS ... habría que
investigar todo eso después de actualizar a las últimas versiones.

-- 
Álvaro Herrerahttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services

-
Enviado a la lista de correo pgsql-es-ayuda (pgsql-es-ayuda@postgresql.org)
Para cambiar tu suscripción:
http://www.postgresql.org/mailpref/pgsql-es-ayuda

[pgsql-es-ayuda] Solicitud de Ponencias. Reunión de Usuarios de Linux y PostgreSQL en Guadalajara, México.

2013-09-26 Por tema Roberto Andrade Fonseca 
Convocatoria
1a Reunión de Usuarios de Linux y PostgreSQL en el Bajío.
Guadalajara, Jal. 17 y 18 de octubre, de 10 a 14 y de 16 a 19 horas.

Se convoca a proponer pláticas de proyectos, casos de éxito, desarrollos o
trabajos en desarrollo acerca de Linux y PostgreSQL.

Se seleccionarán en total 14 ponencias: 7 de Linux y 7 de PostgreSQL.

Se expondrán 7 ponencias cada día en las instalaciones de Lanxe en IJALTI.
Instituto Jalisciense de Tecnologías de la Información
Av. López Mateos Sur 2077-Z, Col. Jardines de Plaza del Sol
C.P. 44510, Guadalajara, Jalisco, México.

Envió de propuestas y dudas a randradefons...@gmail.com

Pronto contaremos con una página en dónde publicaremos detalles del evento.

-- 
Roberto Andrade Fonseca

Re: [pgsql-es-ayuda] Auxilio Ejecuto consulta y el servicio se apaga adjunto detalle

2013-09-26 Por tema jvenegasperu . 
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"

he seguido probando las consultas he bajado los parametros de shared
buffers y work_mem y la consulta paso los volvi a subir a como estaban y
tambien funciono en algunas ocasiones la consulta pasa y en otras
simplemente apaga el servicio de postgres

que mas podria revisar










El 26 de septiembre de 2013 12:43, Alvaro Herrera
escribió:

> Jaime Casanova escribió:
> > 2013/9/26 jvenegasperu . :
> > >
> > > el servicio postgres se apaga
> > >
> > > Esto es lo que reporta el log, trabajo en windows 7 con postgres 9.1
> >
> > Saludos,
> >
> > ese error es "access violation", y por los mensajes en el log puede
> > provenir de postgis.
> > puedes mostrar las versiones exactas de postgres y postgis?
>
> La cantidad de memoria reportada es muy grande.  Hay como 1 GB en
> TopMemoryContext y otros 700 MB en un contexto del ejecutor.  Es muy
> posible que haya una fuga de memoria en PostGIS ... habría que
> investigar todo eso después de actualizar a las últimas versiones.
>
> --
> Álvaro Herrerahttp://www.2ndQuadrant.com/
> PostgreSQL Development, 24x7 Support, Training & Services
>



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

mails: jvenegasp...@php.net
  jvenegasp...@gmail.com

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

Re: [pgsql-es-ayuda] Auxilio Ejecuto consulta y el servicio se apaga adjunto detalle

2013-09-26 Por tema Jaime Casanova 
2013/9/26 jvenegasperu . :
> 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

-- 
Jaime Casanova www.2ndQuadrant.com
Professional PostgreSQL: Soporte 24x7 y capacitación
Phone: +593 4 5107566 Cell: +593 987171157

-
Enviado a la lista de correo pgsql-es-ayuda (pgsql-es-ayuda@postgresql.org)
Para cambiar tu suscripción:
http://www.postgresql.org/mailpref/pgsql-es-ayuda

Re: [pgsql-es-ayuda] Auxilio Ejecuto consulta y el servicio se apaga adjunto detalle

2013-09-26 Por tema Alvaro Herrera 
Jaime Casanova escribió:
> 2013/9/26 jvenegasperu . :
> > 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 Herrerahttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services

-
Enviado a la lista de correo pgsql-es-ayuda (pgsql-es-ayuda@postgresql.org)
Para cambiar tu suscripción:
http://www.postgresql.org/mailpref/pgsql-es-ayuda

Re: [pgsql-es-ayuda] Auxilio Ejecuto consulta y el servicio se apaga adjunto detalle

2013-09-26 Por tema jvenegasperu . 
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
escribió:

> Jaime Casanova escribió:
> > 2013/9/26 jvenegasperu . :
> > > 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 Herrerahttp://www.2ndQuadrant.com/
> PostgreSQL Development, 24x7 Support, Training & Services
>



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

mails: jvenegasp...@php.net
  jvenegasp...@gmail.com

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

[pgsql-es-ayuda] buenas practicas de programación

2013-09-26 Por tema raul andrez gutierrez alejo 
Hola Lista.

Deseo saber si alguien conoce una guiá de buenas practicas para desarrollo
en postgres.

Por ejemplo me eh dado cuenta que cuando se tiene un campo fecha_registro
de tipo timestamp y deseo buscar los registro de un día lo mejor es crear
un indice de tipo date asi:

CREATE INDEX indx_tabla_fecha_registro
  ON tabla
  USING btree
  (date(fecha_registro));

y el select agregare en el  where cast(fecha_registro AS date ) =
'2013-09-26'

el cast obliga a usar el indice ( indx_tabla_fecha_registro) y la consulta
puede ser 10 veces mas rápida cuando la tabla tiene millones de registros.

estuve buscando en google pero no encontré nada que recopile
recomendaciones para que el sql en postgres sea mas rápido.

alquien conoce un articulo o puede aportar algunos tips.


-- 
Raul Andres Gutierrez Alejo

Re: [pgsql-es-ayuda] Auxilio Ejecuto consulta y el servicio se apaga adjunto detalle

2013-09-26 Por tema Felipe Guzman 
Solo para salir de la duda
ambas coberturas se encuentran en la misma proyección?


El 26 de septiembre de 2013 18:47, jvenegasperu .
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 <
> alvhe...@2ndquadrant.com> escribió:
>
> Jaime Casanova escribió:
>> > 2013/9/26 jvenegasperu . :
>> > > 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 Herrerahttp://www.2ndQuadrant.com/
>> PostgreSQL Development, 24x7 Support, Training & Services
>>
>
>
>
> --
> José Mercedes Venegas Acevedo
> cel: Mov. 949808846
>
> mails: jvenegasp...@php.net
>   jvenegasp...@gmail.com
>
> PHP Spanish Docs translator member.
> http://www.php.net/manual/es/index.php
>



-- 
Felipe Guzman Vargas

Re: [pgsql-es-ayuda] Auxilio Ejecuto consulta y el servicio se apaga adjunto detalle

2013-09-26 Por tema jvenegasperu . 
Si claro todas las geometrias estan en la misma proyeccion



El 26 de septiembre de 2013 19:59, Felipe Guzman
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 . 
> 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 <
>> alvhe...@2ndquadrant.com> escribió:
>>
>> Jaime Casanova escribió:
>>> > 2013/9/26 jvenegasperu . :
>>> > > 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 Herrerahttp://www.2ndQuadrant.com/
>>> PostgreSQL Development, 24x7 Support, Training & Services
>>>
>>
>>
>>
>> --
>> José Mercedes Venegas Acevedo
>> cel: Mov. 949808846
>>
>> mails: jvenegasp...@php.net
>>   jvenegasp...@gmail.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: jvenegasp...@php.net
  jvenegasp...@gmail.com

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