Re: [pgsql-es-ayuda] Ayuda con integrity_constraint_violation
El 20 de junio de 2016, 11:39, Alvaro Herrera <alvhe...@2ndquadrant.com> escribió: > motum hesa escribió: > > Hay campos en la excepción que indican la restricción y tabla > involucradas; mira 40.6.6.1 (tabla 40-1) en > > https://www.postgresql.org/docs/9.5/static/plpgsql-control-structures.html#PLPGSQL-ERROR-TRAPPING > Esto es relativamente nuevo, quizás 9.4. > > -- > Álvaro Herrerahttp://www.2ndQuadrant.com/ > PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services > Muchas gracias, afortunadamente también están disponibles para PostgreSQL 9.3 (la versión que está instalada). Las voy a probar inmediatamente. Y regreso con los resultados. Saludos!
[pgsql-es-ayuda] Ayuda con integrity_constraint_violation
Hola lista. En una de las tablas que hay en la base de datos, existe un trigger AFTER INSERT con la siguiente estructura: CREATE OR REPLACE FUNCTION checatabla() RETURNS trigger AS $BODY$ DECLARE BEGIN BEGIN SELECT INTO var1; SELECT INTO var2; UPDATE; IF THEN INSERT END IF; IF THEN INSERT END IF; SELECT INTO ; IF FOUND THEN SELECT INTO var4; IF THEN UPDATE; ELSIF THEN UPDATE; END IF; ELSE SELECT INTO var5; IF THEN INSERT; ELSIF THEN INSERT; END IF; END IF; EXCEPTION WHEN integrity_constraint_violation THEN RAISE WARNING 'Existe una excepcion'; END; return NEW; END; Esta tabla es modificada por un proceso y recientemente en el log de postgres sale mucho el mensaje que está en el RAISE WARNING, tengo entendido que integrity_constraint_violation engloba cualquier error (violacion de llaves foraneas, checks, uniques, llaves primarias) por lo que me es difícil saber cual está sucendiendo, es posible saber en qué tabla y qué error está sucediendo? Muchas gracias de antemano. Saludos
[pgsql-es-ayuda] Instalación de Postgis en FreeBSD sobre PostgreSQL 9.5
Que tal. Durante estos días he tratado de instalar PostGIS 2.x en máquinas virtuales con FreeBSD 9.3/10.2 sobre PostgreSQL 9.5, tratando de instalar PostGIS 2.0.7 / 2.1.7 desde los ports genera el siguiente error: : recipe for target 'lwgeom_accum.o' failed gmake[2]: *** [lwgeom_accum.o] Error 1 gmake[2]: Leaving directory '/usr/ports/databases/postgis20/work/postgis-2.0.7/postgis' GNUmakefile:14: recipe for target 'all' failed gmake[1]: *** [all] Error 1 gmake[1]: Leaving directory '/usr/ports/databases/postgis20/work/postgis-2.0.7' Makefile:6: recipe for target 'all' failed gmake: *** [all] Error 2 ===> Compilation failed unexpectedly. Try to set MAKE_JOBS_UNSAFE=yes and rebuild before reporting the failure to the maintainer. *** [do-build] Error code 1 Tampoco he tenido suerte tratando de instalar PostGIS 2.2 desde los fuentes, en dónde genera el siguiente error: cc: error: linker command failed with exit code 1 (use -v to see invocation) Makefile:103: recipe for target 'shp2pgsql' failed gmake[2]: *** [shp2pgsql] Error 1 gmake[2]: Leaving directory '/root/postgis-2.2.1/loader' GNUmakefile:16: recipe for target 'all' failed gmake[1]: *** [all] Error 1 gmake[1]: Leaving directory '/root/postgis-2.2.1' *** Error code 2 Stop. make: stopped in /root/postgis-2.2.1 Desinstalar PostgreSQL 9.5 y regresar a una versión anterior no funciona. La única forma que funciona la instalación es: Instalando PostgreSQL 9.3 y después instalando postgis desde los ports (cualquier versión). Alguno de ustedes se ha encontrado con este problema?. Gracias de antemano
[pgsql-es-ayuda] Loggear consultas de triggers
Buenas tardes. Actualmente en un servidor estoy teniendo unos problemas pues un Insert está tardando más de 5 segundos, esta tabla tiene un trigger AFTER INSERT en este trigger se realizan algunos cálculos y consulta a otra tabla, una vez realizado los datos que están aquí son insertados a otra tabla, esta otra tabla a su vez tiene un trigger BEFORE INSERT, este es el trigger más pesado (más de 2 mil lineas) y realiza consultas, llamadas a funciones y al final inserta los datos procesados a una tabla histórica. Desgraciadamente el log de PostgreSQL sólo me dice que el INSERT está tardando mucho, me gustaría saber qué consultas dentro del trigger están tardando tanto para poder empezar a optimizarlas,¿es esto posible?. Intente con log_statement=all pero no me sirivió mucho Estoy usando PostgreSQL 9.3.8 en FreeBSD 10.1 Muchas gracias de antemano.
Re: [pgsql-es-ayuda] Loggear consultas de triggers
Gracias, utilizaré sus consejos. El 19 de agosto de 2015, 15:26, Gerardo Herzig gher...@fmed.uba.ar escribió: Yo en esos casos de apuro opto por el depurador del hombre pobre: Encierro las partes que quiero depurar con inicio = clock_timestamp(); .. .. [codigo codigo] fin = clock_timestamp(); raise notice 'tiempo de bloque de ejecucion = %', fin - inicio; Tambien podrias, claro, guardar los tiempos en una tabla. Supongo que con un par de iteraciones lograras encontrar la parte lenta. HTH Gerardo - Mensaje original - De: motum hesa mot...@gmail.com Para: Lista PostgreSQL pgsql-es-ayuda@postgresql.org Enviados: Miércoles, 19 de Agosto 2015 17:14:44 Asunto: [pgsql-es-ayuda] Loggear consultas de triggers Buenas tardes. Actualmente en un servidor estoy teniendo unos problemas pues un Insert está tardando más de 5 segundos, esta tabla tiene un trigger AFTER INSERT en este trigger se realizan algunos cálculos y consulta a otra tabla, una vez realizado los datos que están aquí son insertados a otra tabla, esta otra tabla a su vez tiene un trigger BEFORE INSERT, este es el trigger más pesado (más de 2 mil lineas) y realiza consultas, llamadas a funciones y al final inserta los datos procesados a una tabla histórica. Desgraciadamente el log de PostgreSQL sólo me dice que el INSERT está tardando mucho, me gustaría saber qué consultas dentro del trigger están tardando tanto para poder empezar a optimizarlas,¿es esto posible?. Intente con log_statement=all pero no me sirivió mucho Estoy usando PostgreSQL 9.3.8 en FreeBSD 10.1 Muchas gracias de antemano.
Re: [pgsql-es-ayuda] Cambiar
El 11 de junio de 2015, 10:30, Alvaro Herrera alvhe...@2ndquadrant.com escribió: motum hesa escribió: Para hacer esto he intentado los siguientes comandos de initdb: /usr/local/etc/rc.d/postgresql initdb -E UTF8 --xlogdir=/dbe/pgsql/pg_xlog/ /usr/local/etc/rc.d/postgresql initdb -E UTF8 -X /dbe/pgsql/pg_xlog/ Luego de eso, pg_xlog en /data debería ser un symlink al directorio indicado. Pero noto que no indicaste que /data es el directorio de datos, así que posiblemente puso el nuevo directorio de datos en otra parte ... A todo esto, espero que no estés tratando de modificar las cosas en una instancia que ya contiene datos. Para esto, puedes 1. bajar el motor 2. crear el directorio .../pgxlog 3. mover los archivos desde pgdata/pg_xlog a .../pgxlog 4. crear un symlink desde pgdata/pg_xlog a .../pgxlog 5. iniciar el motor Hola muchas gracias por la respuesta. Estoy ejecutando esto en un entorno de pruebas, así que puedo hacer y deshacer sin problema. La razón por la que no he indicado en dónde debería estar el directorio /data es porque por mi está bien que se quede en su lugar por default ya que ahí estará en otro arreglo de discos. Entonces, si te he entendido bien tendría que hacer lo siguiente: 1. Ejecutar /usr/local/etc/rc.d/postgresql initdb -E UTF8 -X /dbe/pgsql/pg_xlog/ 2. Mover archivos de /data/pg_xlog a /dbe/pgsql/pg_xlog/ 3. Crear un symlink ln -s /data/pg_xlog /dbe/pgsql/pg_xlog/ 4. Iniciar Postgres Esto sería lo correcto? Muchas gracias!
Re: [pgsql-es-ayuda] servidores postgresql 9.4
El 11 de junio de 2015, 11:27, Luis Felipe Aguilar Pereda luchitodesig...@gmail.com escribió: Estimados, alguien sabe si hay servidores que den este servicio online, gratis o de paga?. gracias por los datos. -- Aguilar Pereda Luis Claro: 952226115 Hola. EnterpriseDB tiene este servicio: http://www.enterprisedb.com/Cloud Saludos
Re: [pgsql-es-ayuda] Cambiar
Ah, ahora entiendo el problema. En vez de ejecutar initdb, estás invocando la función initdb del script de inicio de FreeBSD. Es muy posible que ese código no conozca sobre el switch -X y por eso no funciona. Una solución sería ejecutar initdb directamente en vez de usar el script, supongo, pero sólo después de hacer un reporte de bug al package de FreeBSD para que soporte la opción -X. Hola. Gracias por indicarme lo del script initdb. He visto el script y simplemente tenía que poner esto en el rc.conf: postgresql_initdb_flags=--encoding=utf-8 --xlogdir=/database/pgsql/pg_xlog/ Ejecutar el comando /usr/local/etc/rc.d/postgresql initdb Y listo! Se ha solucionado todo. Muchas gracias!
[pgsql-es-ayuda] Cambiar
Hola a todos. Tengo un servidor usando FreeBSD 10.1 en el que he instalado PostgreSQL 9.3 desde los ports. He leído que para mejorar un poco el rendimiento es buena idea tener el directorio pg_xlog en un arreglo de discos separado. Para hacer esto he intentado los siguientes comandos de initdb: /usr/local/etc/rc.d/postgresql initdb -E UTF8 --xlogdir=/dbe/pgsql/pg_xlog/ /usr/local/etc/rc.d/postgresql initdb -E UTF8 -X /dbe/pgsql/pg_xlog/ Sin embargo, al verificar dentro de la carpeta /data de PostgreSQL existe todavía el directorio pg_xlog y también contiene archivos mientras que el directorio especial que he creado /dbe/pgsql/pg_xlog/ está vacío, al crear base de datos de pruebas sigue sin usar el directorio que yo he asignado. Me podrían indicar si estoy haciendo algo mal?. Muchas graciasy saludos
[pgsql-es-ayuda] Re: [pgsql-es-ayuda] Re: [pgsql-es-ayuda] Re: [pgsql-es-ayuda] Re: [pgsql-es-ayuda] Error 08003 en ejecución local
Hola Jaime Soler, si tengo contemplada esa excepcion por la cual ya no puedo recuperar la conexion por la que termino matando el proceso para que intente nuevamente en una nueva ejecucion. Ahi a lo mejor no es lo correcto, pero por el momento es lo que me esta funcionando. Gracias por el comentario y si tienes alguna idea mas es bienvenida. Saludos Motum El 12 de mayo de 2014, 7:17, jaime soler jaime.so...@gmail.com escribió: El vie, 02-05-2014 a las 19:46 -0500, motum hesa escribió: Hola revise lo del SELINUX, no lo tiene mi sistema operativo, creo que en FREEBSD se llama de otra forma pero la verdad no tengo idea si esta activado, ya hable con la persona que se encarga de los servidores para que lo cheque. En cuanto a las opciones de logs_connections y log_disconnections al activarlas puedo ver lo siguiente: [unknown]: 2014-05-02 23:55:08 UTC : pgsql@[local] web :LOG: connection authorized: user=pgsql database=web [unknown]: 2014-05-02 23:55:08 UTC : pgsql@[local] web :LOG: disconnection: session time: 0:00:00.096 user=pgsql database=web host=[local] Esto se repite muchas veces algunos tiempos llegan a algunos segundos pero, como pueden ver hay conexiones que no duran ni un segundo, no entiendo esto pero tratare de investigar mas con la información que me arrojo el log. Muchas gracias por la ayuda. Saludos ¿Y en la aplicación tienes la pila de excepciones cuando da el error 08003 ? El 2 de mayo de 2014, 14:42, Jaime Casanova ja...@2ndquadrant.com escribió: 2014-05-02 13:52 GMT-05:00 motum hesa mot...@gmail.com: Gracias por la recomendación Cesar, justamente así se hace normalmente, sin embargo este es el tercer conjunto de servidores que se instala y por cuestiones monetarias comenzamos con el programa de JAVA en el mismo server hasta que sea adecuado contratar el segundo. Jaime te mando la información relevante del archivo pg_hba.conf: local all all trust # IPv4 local connections: hostall all 127.0.0.1/32 trust hostall all 198.xxx.xxx.xxx/32 trust hostall all xxx.xxx.xx.xxx/32 trust hostall slony xxx.xx.xxx.xx/32 md5 la cadena de conexión es para la base de datos de lectura es: jdbc:postgresql://+server+:5432/comm,pgsql, las cadenas de conexión para la base de datos de insercción es: property name=connection.driver_classorg.postgresql.Driver/property property name=connection.urljdbc:postgresql://127.0.0.1/web/property property name=connection.usernamepgsql/property property name=connection.password/property property name=connection.port5432/property Es decir que el problema es usando la ip 127.0.0.1, eso no es conexión local en el sentido que pg_hba.conf lo entiende... en todo caso, aun así no puede ser problema de red. sin mas pistas voy a lanzar una piedra al aire y esperar a atinarle a algo... haz apagado selinux? sino lo has hecho hazlo y veamos si tienes el mismo problema. otra forma de buscar: activa log_connections y log_disconnections -- Jaime Casanova www.2ndQuadrant.com Professional PostgreSQL: Soporte 24x7 y capacitación Phone: +593 4 5107566 Cell: +593 987171157
[pgsql-es-ayuda] Error 08003 en ejecución local
Hola a todos, tengo un problema con un pequeño programa en JAVA que hace insercciones a una tabla con Hibernate, ya trate de descartar cualquier problema con estas tecnologias y solo me queda alguna configuración de postgres, este es el error: WARNING: SQL Error: 0, SQLState: 08003 Por alguna razón solo se da de forma local, ya lo intente de forma remota y funciona correctamente de hecho lo he dejado por horas sin ningun problema, pero cuando lo pongo de forma local corre un par de minutos (haciendo algunas insercciones) y despues manda dicho error. Cabe mencionar que en otro servidor tengo la misma configuracion de todo y funciona perfectamente. Esta es la información del servidor: Version stringPostgreSQL 9.2.8 on amd64-portbld-freebsd9.1, compiled by cc (GCC) 4.2.1 20070831 patched [FreeBSD], 64-bit Saludos y espero sus comentarios... gracias
[pgsql-es-ayuda] Re: [pgsql-es-ayuda] Error 08003 en ejecución local
Muchas gracias por la información Jaime, de hecho deduzco por eso que, por alguna razon el vinculo de conexión entre mi programa y postgres desaparece o lo cierra, por que de primera instancia si existe debido a que si logra realizar varios inserts, y lo que no entiendo es por que de manera remota no da este error y de manera local es casi inmediato. Te agradecere si tienes mas información acerca de este error, para tratar de ver si alguna configuración o algo pueda solucionarlo. Saludos El 2 de mayo de 2014, 12:44, Jaime Casanova ja...@2ndquadrant.comescribió: 2014-05-02 11:51 GMT-05:00 motum hesa mot...@gmail.com: Hola a todos, tengo un problema con un pequeño programa en JAVA que hace insercciones a una tabla con Hibernate, ya trate de descartar cualquier problema con estas tecnologias y solo me queda alguna configuración de postgres, este es el error: WARNING: SQL Error: 0, SQLState: 08003 Según http://www.postgresql.org/docs/9.3/static/errcodes-appendix.html el código de estado SQL 08003 es connection_does_not_exist -- Jaime Casanova www.2ndQuadrant.com Professional PostgreSQL: Soporte 24x7 y capacitación Phone: +593 4 5107566 Cell: +593 987171157
[pgsql-es-ayuda] Re: [pgsql-es-ayuda] Re: [pgsql-es-ayuda] Error 08003 en ejecución local
Gracias por la recomendación Cesar, justamente así se hace normalmente, sin embargo este es el tercer conjunto de servidores que se instala y por cuestiones monetarias comenzamos con el programa de JAVA en el mismo server hasta que sea adecuado contratar el segundo. Jaime te mando la información relevante del archivo pg_hba.conf: local all all trust # IPv4 local connections: hostall all 127.0.0.1/32trust hostall all 198.xxx.xxx.xxx/32 trust hostall all xxx.xxx.xx.xxx/32 trust hostall slony xxx.xx.xxx.xx/32md5 la cadena de conexión es para la base de datos de lectura es: jdbc:postgresql://+server+:5432/comm,pgsql, las cadenas de conexión para la base de datos de insercción es: property name=connection.driver_classorg.postgresql.Driver/property property name=connection.urljdbc:postgresql://127.0.0.1/web /property property name=connection.usernamepgsql/property property name=connection.password/property property name=connection.port5432/property En el log de postgres no veo nada extraño. Eso es todo lo que tengo, muchas gracias por la ayuda. Motum P.D. Disculpen que les cambie las ips, es por seguridad. El 2 de mayo de 2014, 13:00, Jaime Casanova ja...@2ndquadrant.comescribió: 2014-05-02 12:53 GMT-05:00 motum hesa mot...@gmail.com: Muchas gracias por la información Jaime, de hecho deduzco por eso que, por alguna razon el vinculo de conexión entre mi programa y postgres desaparece o lo cierra, por que de primera instancia si existe debido a que si logra realizar varios inserts, y lo que no entiendo es por que de manera remota no da este error y de manera local es casi inmediato. Te agradecere si tienes mas información acerca de este error, para tratar de ver si alguna configuración o algo pueda solucionarlo. Saludos Podrías mostrar la cadena de conexión? el archivo pg_hba.conf y si es que hay algún mensaje relevante en el log de postgresql? -- Jaime Casanova www.2ndQuadrant.com Professional PostgreSQL: Soporte 24x7 y capacitación Phone: +593 4 5107566 Cell: +593 987171157
[pgsql-es-ayuda] Re: [pgsql-es-ayuda] Re: [pgsql-es-ayuda] Re: [pgsql-es-ayuda] Error 08003 en ejecución local
Hola revise lo del SELINUX, no lo tiene mi sistema operativo, creo que en FREEBSD se llama de otra forma pero la verdad no tengo idea si esta activado, ya hable con la persona que se encarga de los servidores para que lo cheque. En cuanto a las opciones de logs_connections y log_disconnections al activarlas puedo ver lo siguiente: [unknown]: 2014-05-02 23:55:08 UTC : pgsql@[local] web :LOG: connection authorized: user=pgsql database=web [unknown]: 2014-05-02 23:55:08 UTC : pgsql@[local] web :LOG: disconnection: session time: 0:00:00.096 user=pgsql database=web host=[local] Esto se repite muchas veces algunos tiempos llegan a algunos segundos pero, como pueden ver hay conexiones que no duran ni un segundo, no entiendo esto pero tratare de investigar mas con la información que me arrojo el log. Muchas gracias por la ayuda. Saludos El 2 de mayo de 2014, 14:42, Jaime Casanova ja...@2ndquadrant.comescribió: 2014-05-02 13:52 GMT-05:00 motum hesa mot...@gmail.com: Gracias por la recomendación Cesar, justamente así se hace normalmente, sin embargo este es el tercer conjunto de servidores que se instala y por cuestiones monetarias comenzamos con el programa de JAVA en el mismo server hasta que sea adecuado contratar el segundo. Jaime te mando la información relevante del archivo pg_hba.conf: local all all trust # IPv4 local connections: hostall all 127.0.0.1/32trust hostall all 198.xxx.xxx.xxx/32 trust hostall all xxx.xxx.xx.xxx/32 trust hostall slony xxx.xx.xxx.xx/32md5 la cadena de conexión es para la base de datos de lectura es: jdbc:postgresql://+server+:5432/comm,pgsql, las cadenas de conexión para la base de datos de insercción es: property name=connection.driver_classorg.postgresql.Driver/property property name=connection.urljdbc:postgresql://127.0.0.1/web/property property name=connection.usernamepgsql/property property name=connection.password/property property name=connection.port5432/property Es decir que el problema es usando la ip 127.0.0.1, eso no es conexión local en el sentido que pg_hba.conf lo entiende... en todo caso, aun así no puede ser problema de red. sin mas pistas voy a lanzar una piedra al aire y esperar a atinarle a algo... haz apagado selinux? sino lo has hecho hazlo y veamos si tienes el mismo problema. otra forma de buscar: activa log_connections y log_disconnections -- Jaime Casanova www.2ndQuadrant.com Professional PostgreSQL: Soporte 24x7 y capacitación Phone: +593 4 5107566 Cell: +593 987171157
Re: [pgsql-es-ayuda] Redondear enteros para arriba
Con la función que propone felipe, solo sumale 4.9 a tu dato y debe funcionar: Select round(valor::numeric + 4.9, -1) El ene 8, 2014 5:07 p.m., Felipe Hernández pip...@gmail.com escribió: select round(valor::numeric,-1); casi perfecto, pero 191 se redondearia a 190. El 8 de enero de 2014, 18:01, Ivan Garro ivanga...@gmail.com escribió: Hola Equipo, tengo el siguiente problema: necesito redondear valores numericos (enteros o no) a la siguiente decena, siempre para arriba. por ejemplo necesito que me de el siguiente resultado: valorresultado esperado 195 200 199 200 199.25 200 191 200 189 190 190 190 se entiende? he buscado pero no doy con ninguna funcion desde ja Muchas Gracias Ivan - 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 -- fElIpE
Re: [pgsql-es-ayuda] warning en el log
Hola, mira si vienes de una version anterior y funcionaba es posible que el parametro bytea_output no sea igual a '*escape*' como lo era en versiones anteriores. Lo otro que se me ocurre es que cheques el siguiente link: http://wiki.postgresql.org/wiki/What%27s_new_in_PostgreSQL_9.1#Backward_compatibility_issues ahi podrias encontrar otro parametro de configuracion que te esta efectando. Saludos y espero que esto te ayude... Roberto Campos El 5 de julio de 2013 19:15, Guillermo E. Villanueva guillermo...@gmail.com escribió: Amigos estoy leyendo el tema pero la verdad que me cuesta entenderlo del todo. Mis neuronas se están avegentando rapidísimo. :-( Tengo un sistema web php accediendo a un postgres 9.0 El log de este postgres esta llenísimo del siguiente warning: .. .. 2013-07-05 20:53:12 ART HINT: Use la sintaxis de escape para cadenas, por ej. E'\r\n'. 2013-07-05 20:53:16 ART WARNING: uso no estandar de escape en un literal de cadena en car.cter 128 2013-07-05 20:53:16 ART HINT: Use la sintaxis de escape para cadenas, por ej. E'\r\n'. 2013-07-05 20:53:34 ART WARNING: uso no estandar de escape en un literal de cadena en car.cter 132 2013-07-05 20:53:34 ART HINT: Use la sintaxis de escape para cadenas, por ej. E'\r\n'. 2013-07-05 20:53:36 ART WARNING: uso no estandar de escape en un literal de cadena en car.cter 128 2013-07-05 20:53:36 ART HINT: Use la sintaxis de escape para cadenas, por ej. E'\r\n'. 2013-07-05 20:53:36 ART WARNING: uso no estandar de escape en un literal de cadena en car.cter 128 2013-07-05 20:53:36 ART HINT: Use la sintaxis de escape para cadenas, por ej. E'\r\n'. 2013-07-05 20:53:38 ART WARNING: uso no estandar de escape en un literal de cadena en car.cter 132 2013-07-05 20:53:38 ART HINT: Use la sintaxis de escape para cadenas, por ej. E'\r\n'. 2013-07-05 20:53:38 ART WARNING: uso no estandar de escape en un literal de cadena en car.cter 132 2013-07-05 20:53:38 ART HINT: Use la sintaxis de escape para cadenas, por ej. E'\r\n'. 2013-07-05 20:53:38 ART WARNING: uso no estandar de escape en un literal de cadena en car.cter 132 2013-07-05 20:53:38 ART HINT: Use la sintaxis de escape para cadenas, por ej. E'\r\n'. 2013-07-05 20:54:20 ART WARNING: uso no estandar de escape en un literal de cadena en car.cter 128 2013-07-05 20:54:20 ART HINT: Use la sintaxis de escape para cadenas, por ej. E'\r\n'. 2013-07-05 20:54:21 ART WARNING: uso no estandar de escape en un literal de cadena en car.cter 132 2013-07-05 20:54:21 ART HINT: Use la sintaxis de escape para cadenas, por ej. E'\r\n'. 2013-07-05 20:56:40 ART WARNING: uso no estandar de escape en un literal de cadena en car.cter 136 2013-07-05 20:56:40 ART HINT: Use la sintaxis de escape para cadenas, por ej. E'\r\n'. .. .. Me pueden orientar en como hacer que postgres me oriente un poquito mas en que query encuentra el problema? Es posible? Sino, no se a que porción de código ir a corregir. En versión 9.1 directamente el sistema no funciona y casi seguro que es por esto. Desde ya muchas gracias por la ayuda que me puedan brindar Muy buen fin de semana Guillermo Villanueva
Re: [pgsql-es-ayuda] Substring en bytea
Checa cómo saca los datos java por que si lo hace cómo hex por cada byte te devuelve 2 caracteres hexadecimales y por eso ves el doble de datos. Roberto campos El may 21, 2012 12:13 p.m., Ivan Perales M. ivan.pera...@gmail.com escribió: Hola lista buen día, acudo a ustedes por la siguiente cuestión. Estoy trabajando con java, en una columna de tipo bytea inserto los datos binarios de archivos adjuntos, se que no es Lo mejor pero por el momento es Lo que tenemos. En está columna voy agregando la información con algo como data = data ¦¦ :newdata. Esto funciona bien ya que al hacer un length me devuelve los bytes del tamaño del archivo. Pero cuando trato de obtener la información con un substring, supongamos de 100 kb, substring(data from 1 for 102400) en postgres me devuelve los 100 kb exactos, pero en java obtengo un array como de 199 kb y esto pues ya es erróneo. Tendrá algo que ver que la bd este en utf? O sí no, conocen alguna herramienta para leer de forma exadecimal el valor de un byeta y comparar contra Lo que obtengo en java? Saludos y de antemano gracias Solo existen 10 tipos de personas en el mundo, las que saben binario y las que no.
Re: [pgsql-es-ayuda] Consulta anidada con valores nulos
hola según veo la diferencia en la consulta es que no estas filtrando por sector al final de la segunda columna. Saludos El mar 5, 2012 9:16 a.m., Alvaro Hilario king...@gmail.com escribió: Tengo una consulta de la siguiente manera: Nota: Fijarse en la ultima linea de los resultados. select codigo_anomalia as anomalia, sum(medidores) from lecturas_sap_bi where to_char(fecha, '-MM') = '2012-02' and sector = 'Puerto Plata' group by codigo_anomalia order by codigo_anomalia La cual me trae por resultado: AN34;707 AN35;905 AN36;3639 AN37;531 AN38;2471 AN39;1518 ;45910 Y la anido de la siguiente manera: select distinct a.codigo_anomalia as anomalia, (select sum(medidores) from lecturas_sap_bi as b where to_char(b.fecha, '-MM') = '2012-02' and b.sector = 'Puerto Plata' and b.codigo_anomalia = a.codigo_anomalia) as pp from lecturas_sap_bi as a where to_char(a.fecha, '-MM') = '2012-02' group by a.codigo_anomalia order by a.codigo_anomalia Y el resultado es: AN34;707 AN35;905 AN36;3639 AN37;531 AN38;2471 AN39;1518 AN41; ; Alguien me puede orientar porque razón ocurre esto. -- Al_Hilario Company
Re: [pgsql-es-ayuda] Problemas con PostgreSQL 9.1.2
Hola antes que nada gracias por tu respuesta en cunato a lo que preguntas: Que s.o. usas en la 9.1.2? No digas que has pasado de un Unix a Windows por favor. Uso FreeBSD 8.2 64bits en todos los servidores (en el anterior tenia 8.1 pero no hay problema con eso por que un servidor de pruebas lo tengo con 8.2 y postgres 8.4 y funciona bien). Has tuneado el sistema aumentando el numero de semaforos, memoria compartida, descriptores de ficheros, el sistema de archivos y demas? Si he aumetado el numero de semafors, memoria compartida, descriptores de ficheros ( no lo habia hecho pero ya realizado sigue igual). En cuanto al sistema de archivos la unica modificacion fue en el fstab agregar noatime, no se que mas puedo modificar. Supongo que postgres si lo has tuneado acorde con la nueva maquina. Si, ya hice el tuning de postgres lo mejor posible por ahi movi mas datos para ayudarme a mi proceso ( como enable_seqscan=off, constraint_exclusion = on, bytea_output='escape' y statement_timeout=5 min).. pero tambien los cambie en maquina de pruebas y no afecta, Como hiciste el paso de los datos de 8.4 a 9.1, con pg_dumpall o pg_upgrade? Si usaste pg_upgrade, has tenido en cuenta que hay tipos de datos que no puede manejar correctamente y has leido el log/registro? al principio use pg_upgrate, pero como comentas dio problemas con unos datos, despues lo hice un pg_dump pero use el del 8.4 y tambien dio un par de problemas.. y el que funciono bien fue hacer el respaldo de 8.4 con el cliente de 9.1 Uno de los pasos que puede fallar y lo anuncia solo con un warning es el reindex, en especial si hay involucrados tipos de datos que no puede manejar. Hice el reindex pero ningun error aparecio.. todo normal Conforme usas los triggers en 9.1 mejoran los tiempos de ejecucion o son practicamente iguales que al principio? Si mejora es normal, si son iguales, mira que se esten usando los indices de forma correcta, que los planes de ejecucion no esten haciendo cosas raras. La mayoria de los triggers mejoraron un poco, pero no se si fue 9.1 o el aumento de caracteristicas en el servidor, yo creo k los planes de ejecucion estan haciendo cosas raras principalmente en la consulta que te comente.. mi idea era depurar la funcion haciendo linea por linea.. pero no se si es posible.. Ya como ultima opcion, reindexa la bd y analiza. Reindexada y analizada.. todo sigue igual :( Saludos y gracias por tus ideas... Roberto Campos - 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] Problemas con PostgreSQL 9.1.2
Hola Jaime, disculpa la tardanza.. ando corriendo haciendo pruebas y mas.. en cuanto a tus preguntas: puedes mostrar el trigger? esta muy grande ( tal vez tambien sea por ahi el problema ), te explico y si lo requieres con gusto te lo adjunto en un archivo dejarnos ver algo que nos de una idea de que podria ser?cuando dices que se queda trabado y que el statement_timeout lo mata, quiza las consultas dentro del trigger estan muy lentas? Segun lo que encontre es un select con un limit 1... normalmente y en el psql esta consulta tarda 100ms exageradamente pero dentro de plpgsql tarda mas de 5 min, te paso el log: ERROR: canceling statement due to statement timeout 2011-12-23 03:20:58 UTC : pgsql@216.24.251.210 motumweb :CONTEXT: SQL statement select point_geom, fechacreacion, importacionid, odometrototal from datosentrada_his where viajeactivo = p_viajesis and entrandosaliendo=1 order by importacionid limit 1 aqui la consideracion mas importante es que la tabla datosentrada_his es una tabla con unas 50 columnas ( se que debo normalizarla, pero me esta costando trabajo por todo lo ya desarrollado) la cual tiene unos 80 millones de registros, debido a eso se particiono, y como los datos se ingresan cada seg aprox. entonces particione por semana donde obtengo particiones de 2.5 millones de registros por particion ( me gustaria saber si es demasiado cada semana segun tu opinion), ahorita tengo unas 18 particiones, 15 llenas, la actual y 2 mas para las proximas semanas. Creo que por aqui el planeador de consultas de postgresql 9.1 esta haciendo algo raro con respecto al 8.4; ya intente meter en la consulta la fecha dentro del where pero no ayudo ( esto debido a que mi particion la hago por fechas) , estoy buscando a ver si despues de que se termina cada parcition puedo agregar algun check para que tambien tome encuentra otras columnas que uso para busqueda de informacion como el importacionid que lo ves en la consulta y el viajeactivo tambien mostrado en la consulta del log. Por desgracia no puedo hacer estos check antes por que no se en que numeros empezaran dentro de cada particion y tampoco en cuales terminaran. Otra consideración es que tengo un trigger de 2500 lineas... no se ejecutan todas cada vez.. esta partido en 4 dependiendo de como llegue la información es lo que se va hacer.. estoy trabajando en conjunto con los programadores para eliminar lineas de este trigger que pueden afectar el desempeño.. pero por el momento solo pegan en cierto casos espcificos que casi no suceden. has ejecutado VACUUM ANALYZE? Si en este servidor recien desplege el respaldo se hizo un vacuum analyze, despues de checar algunas pruebas hice otro... y normalmente en produccion tengo un cron que hace todas las noches el vacuum analyze. Tienen por casualidad tus tablas columnas INET con indices asociados? Rafael en cuanto a tu pregunta no tengo ninguna columa INET.. si tienes alguna otra idea es bien recibida. Gracias Bueno gracias a todos y espero puedan darme mas ideas de donde buscar. Saluds Roberto Campos - 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] Problemas con PostgreSQL 9.1.2
Hola, quiero pensar que nadie ha leído mi post o tal vez nadie tiene un problema así y solo es un caso de mal diseño, por lo que pido a alguien si tiene algún link, post o documento que me pueda compartir para checar mis funciones, casi siempre se atoran en SELECT a tablas particionadas, cosa que no pasaba en 8.4.4. Espero puedan ayudarme con alguna lectura. Ahora bien recuerdo que cuando se anuncio postgresql 9 entre las nuevas características según leí iba a traer una forma de ejecutar línea a línea funciones o procedimientos almacenados... si no es así corríjanme, de lo contrario igual un manual o un link me serviría mucho.. Gracias. y saludos.. El día 20 de diciembre de 2011 17:56, motum hesa mot...@gmail.com escribió: Que tal. Actualmente tenemos 2 servidores de producción (con diferentes características), 1 con PostgreSQL 8.4.4 y otro con PostgreSQL 9.1.2, estamos intentando migrar al 9.1.2 ya que donde se encuentra es un servidor más potente, tenemos una aplicación en JAVA que hace INSERTS a una tabla en especial, esta tabla tiene triggers que hace operaciones a otras tablas (SELECTS, UPDATES, INSERTS), y es aquí donde nos encontramos con los problemas ya que cuando el trigger quiere realizar alguna de estas operaciones se quedan trabadas (se mueren gracias al statement_timeout que está a 5 minutos en ambos servidores), eso solo pasa en 9.1.2 ya que la misma aplicación está en el otro servidor funcionando sin ningún problema. Alguna idea del porqué PostgreSQL 9.1.2 se está comportando de esa manera? Gracias de antemano. - 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] Problemas con PostgreSQL 9.1.2
Que tal. Actualmente tenemos 2 servidores de producción (con diferentes características), 1 con PostgreSQL 8.4.4 y otro con PostgreSQL 9.1.2, estamos intentando migrar al 9.1.2 ya que donde se encuentra es un servidor más potente, tenemos una aplicación en JAVA que hace INSERTS a una tabla en especial, esta tabla tiene triggers que hace operaciones a otras tablas (SELECTS, UPDATES, INSERTS), y es aquí donde nos encontramos con los problemas ya que cuando el trigger quiere realizar alguna de estas operaciones se quedan trabadas (se mueren gracias al statement_timeout que está a 5 minutos en ambos servidores), eso solo pasa en 9.1.2 ya que la misma aplicación está en el otro servidor funcionando sin ningún problema. Alguna idea del porqué PostgreSQL 9.1.2 se está comportando de esa manera? Gracias de antemano. - 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] Re: [pgsql-es-ayuda] In Memoriam: Falleció Dennis Ritchie
++; El oct 14, 2011 4:03 p.m., Marcos Luis Ortiz Valmaseda marcosluis2...@googlemail.com escribió: El 14 de octubre de 2011 15:30, Espartano espartano.m...@gmail.comescribió: Aquí un link de Rob Pike con algunos pensamientos de los grandiosos legados de Dennis Ritchie... ++ -- Marcos Luis Ortíz Valmaseda Linux Infrastructure Engineer Linux User # 418229 http://marcosluis2186.posterous.com http://www.linkedin.com/in/marcosluis2186 Twitter: @marcosluis2186
Fwd: [pgsql-es-ayuda] Problema uso de indices...
Pues muchas gracias a todos y principalmente a Alvaro, La solución a esta cuestión es crear indices multicolumna donde sean necesarios. Espero le sirva a alguien esto. Saludos. Roberto Campos - 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] Problema uso de indices...
Uh, después de mirarlo otra vez, es obvio que hace lo mismo porque en el plan no hay ningún seqscan, sino un indexscan. Prueba poniendo enable_indexscan TO off. Esto debería hacer que empiece a usar el bitmapscan que es el plan rápido. Definitivamente uso ahora un bitmapscan y aunque mejoro un poco la velocidad, no fue tanto como quisiera, pero bueno ya es ganancia. Creo que tendre que quedarme con la opcion de crear indices aunque sean repetidos. Ahora bien.. me conviene dejar por default el enable_indexscan y el enable_seqscan en off desde el postgresql.conf para optimizar en general mis consultas? -- Álvaro Herrera alvhe...@alvh.no-ip.org No he podido probar los parametros del Planner Cost, tratare de hacerlo el fin de semana ya que no tenga tantos clientes conectados. Saludos y gracias por su ayuda nuevamente Roberto Campos - 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] Problema uso de indices...
Hm, raro. Muestra el \d de la tabla otra vez por favor, en ambos servidores. Muestra también el resultado de Server 1 Table public.datosentrada_his Column|Type | Modifiers -+-+--- fechaentrada| timestamp without time zone | lat | double precision| lng | double precision| direccion | character varying | entrandosaliendo| integer | odometrototal | double precision| hrastotalmotor | double precision| hrastotalpto| double precision| hrastotalralenti| double precision| combustotalralenti | double precision| combustotalpto | double precision| bateria | double precision| altitud | double precision| factorcarga | double precision| torque | double precision| conexiontrailer1| integer | conexiontrailer2| integer | refpunto| integer | refciudad | integer | unitno | character varying(15) | not null flota | character varying(40) | not null importacionid | bigint | not null viajeactivo | integer | cro | integer | ignicion| boolean | pia | integer | fechaenvio | timestamp without time zone | fechacreacion | timestamp without time zone | point_geom | geometry| point_geomutm | geometry| combustibletotal| double precision| dkilometros | double precision| dhoraspto | double precision| dhorasmotor | double precision| dcombustible| double precision| velpromedio | double precision| dhorasralenti | double precision| default 0 nalarmas| smallint| default 0 nfallas | smallint| default 0 nmensajes | smallint| default 0 tempmotor | double precision| tempaceite | double precision| presionturbo| double precision| presionaceite | double precision| rpm | integer | tiempo_optimas_rpm | double precision| default 0 tiempo_retarder | double precision| default 0 dcombustibleralenti | double precision| dcombustiblepto | double precision| dtiempo_optimas_rpm | double precision| dtiempo_retarder| double precision| mrefp | double precision| mrefc | double precision| pendientes | smallint| pos_gps | boolean | minrpm | integer | engrane_transmision | integer | vel_max | double precision| compre_break_dis| double precision| cont_apli_fren | integer | cont_ace_brusca | integer | cont_desac_brusca | integer | total_eng_cruise| double precision| odom_virtual| double precision| num_sate| integer | vel_gps | integer | edobatt | smallint| Indexes: datosentrada_his_pk PRIMARY KEY, btree (importacionid) fki_importacionid_his btree (importacionid) fki_vehiculo_his btree (unitno, flota) fki_viajeactivo_his btree (viajeactivo) ind_fecha btree (fechacreacion) inf_fecha_id_his btree (fechacreacion, importacionid) Check constraints: enforce_dims_point_geom CHECK (ndims(point_geom) = 2) enforce_dims_point_geomutm CHECK (ndims(point_geomutm) = 2) enforce_geotype_point_geom CHECK (geometrytype(point_geom) = 'POINT'::text OR point_geom IS NULL) enforce_geotype_point_geomutm CHECK (geometrytype(point_geomutm) = 'POINT'::text OR point_geomutm IS NULL) enforce_srid_point_geom CHECK (srid(point_geom) = 4326) enforce_srid_point_geomutm CHECK (srid(point_geomutm) = 32614) Foreign-key constraints: historico_vehiculo FOREIGN KEY (unitno, flota) REFERENCES vehiculos(unitno, flota) ON UPDATE CASCADE Triggers: pdatosentrada_his_trig BEFORE INSERT ON datosentrada_his FOR EACH ROW EXECUTE PROCEDURE pdatosentrada_his_func() Server 2
[pgsql-es-ayuda] Problema uso de indices...
Hola disculpen la molestia nuevamente, he estado tratando de optimizar una consulta que ya habia optimizado pero el cliente me aviso que estaba tardando demasiado, lo raro de el caso es que la misma base de datos la respalde y la desplegue un par de semanas atras en un servidor de pruebas, donde se estan insertando los mismos registros diariamente, en el servidor de produccion ( server 1) la consulta tarda mas de 170 segundos en realizarse mientras en el servidor de pruebas ( server 2) tarda 2 o 3 segundos... hice un explain analyze en la consulta y despues de revizarla me doy cuenta que por alguna razon en el server 1 el indice que tengo sobre un timestamp no se esta usando, hice un backup del esquema y lo compare con el de server 1 y la estructura es la misma ( solo habia una funcion nueva en el server 2 pero no es relevante para la consulta). Hice otra prueba para ver si es por la configuracion de hardware donde server 1 esta como sigue: 2 Xeon a 2 Ghz 6Gb RAM 150 GB SATA a 10Krpm X 4 Disco duro en RAID 10 Freebsd 8.1 Postgres 8.4.4 el server 2 esta como sigue: 1 Xeon a 2 Ghz 8 GB RAM 300 GB a 7.2K rpm Disco duro sin RAID Freebsd 8.1 Postgres 8.4.4 Y los dos servidores de postgres han sido tuneados para usar los recursos del sistema. Entre las posibles opciones se penso que un disco del Arrglo RAID 10 pudiera estar fallando o tal vez se requiere mas memoria para la consulta ( La tabla tiene mas de 30M de registros), por lo que en un servidor que tengo para otras aplicaciones mas simples tengo un postgres y lo use para hacer un respaldo del server 1 y del server 2 y los desplege en este server 3: Xeon 2 GHz 2 GB RAm 150 GB x 2 a 7.2K rmp en RAID 1 Freebsd 8 Postgres 8.4.2 Donde el resultado es el mismo bdserver1 180segundos la consulta y dbserver2 5 segundo la consulta. Ya Recree el indice que me hace falta que se use, hice vacuum, vacuum analyze, reindex y nada no se mas puedo hacer, espero puedan ayudarme, la consulta es la siguiente: SELECT DE.unitno,DE.entrandosaliendo,DE.fechacreacion, DE.lat,DE.lng,DE.odometrototal, DE.odometrototal as copodo,DE.combustibletotal, TE.nombre,TE.img, TE.ops,EA.valor,EF.descripcion, EF.fault_codes,EF.tipo,EM.descripcion as desmssg, DE.pos_gps FROM (select * from datosentrada_his where unitno='111' and flota='EMPRESA1' and fechacreacion between '07/13/2011 05:00' and '07/15/2011 04:59' ) AS DE LEFT JOIN entradafallas AS EF USING(importacionid) LEFT JOIN entradaalarma AS EA USING(importacionid) LEFT JOIN entradamensajes AS EM USING(importacionid) LEFT JOIN tipoevento AS TE ON EA.tipo = TE.tipo ORDER BY DE.fechacreacion ASC Si es necesario les puedo enviar el resultado de los explain analyze que realice.. Espero puedan ayudarme... ya que he leido todo lo que he encontrado y nada. mi principal duda es por que en una db si se usa el indice y en la otra no... Roberto Campos - 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] Problema uso de indices...
Este es el resultado del explain analyze en el server 1: QUERY PLAN - Sort (cost=1718.18..1718.21 rows=57 width=519) (actual time=175459.691..175463.798 rows=2865 loops=1) Sort Key: public.datosentrada_his.fechacreacion Sort Method: quicksort Memory: 446kB - Hash Left Join (cost=16.76..1717.85 rows=57 width=519) (actual time=81664.931..175446.958 rows=2865 loops=1) Hash Cond: (public.datosentrada_his.importacionid = em.importacionid) - Nested Loop Left Join (cost=0.00..1700.63 rows=11 width=495) (actual time=81664.848..175435.842 rows=2865 loops=1) - Nested Loop Left Join (cost=0.00..1660.14 rows=5 width=254) (actual time=81618.484..175341.231 rows=2865 loops=1) Join Filter: (ea.tipo = te.tipo) - Nested Loop Left Join (cost=0.00..1654.23 rows=5 width=76) (actual time=81605.823..175048.216 rows=2865 loops=1) - Append (cost=0.00..1621.58 rows=4 width=58) (actual time=81551.393..174852.044 rows=2865 loops=1) - Index Scan using fki_vehiculo_his on datosentrada_his (cost=0.00..1621.58 rows=4 width=58) (actual time=81551.387..174843.074 rows=2865 loops=1) Index Cond: (((unitno)::text = '142'::text) AND ((flota)::text = 'Transportes Bueno'::text)) Filter: ((fechacreacion = '2011-07-13 05:00:00'::timestamp without time zone) AND (fechacreacion = '2011-07-15 04:59:00'::timestamp without time zone)) - Index Scan using ea_importacionid on entradaalarma ea (cost=0.00..8.16 rows=1 width=26) (actual time=0.063..0.063 rows=0 loops=2865) Index Cond: (public.datosentrada_his.importacionid = ea.importacionid) - Seq Scan on tipoevento te (cost=0.00..1.08 rows=28 width=186) (actual time=0.008..0.050 rows=28 loops=2865) - Index Scan using imid on entradafallas ef (cost=0.00..8.09 rows=2 width=249) (actual time=0.028..0.028 rows=0 loops=2865) Index Cond: (public.datosentrada_his.importacionid = ef.importacionid) - Hash (cost=13.12..13.12 rows=1040 width=40) (actual time=0.006..0.006 rows=0 loops=1) - Seq Scan on entradamensajes em (cost=0.00..13.12 rows=1040 width=40) (actual time=0.002..0.002 rows=0 loops=1) Total runtime: 175468.194 ms (21 rows) y Este es el del server 2 QUERY PLAN -- Sort (cost=4650.54..4650.64 rows=190 width=519) (actual time=5074.391..5078.896 rows=2865 loops=1) Sort Key: public.datosentrada_his.fechacreacion Sort Method: quicksort Memory: 446kB - Hash Left Join (cost=4347.73..4649.11 rows=190 width=519) (actual time=922.145..5062.929 rows=2865 loops=1) Hash Cond: (public.datosentrada_his.importacionid = em.importacionid) - Nested Loop Left Join (cost=4330.97..4630.83 rows=36 width=495) (actual time=922.101..5052.662 rows=2865 loops=1) - Hash Left Join (cost=4330.97..4501.28 rows=16 width=254) (actual time=877.626..4979.360 rows=2865 loops=1) Hash Cond: (ea.tipo = te.tipo) - Nested Loop Left Join (cost=4329.79..4500.04 rows=16 width=76) (actual time=877.411..4968.538 rows=2865 loops=1) - Append (cost=4329.79..4385.75 rows=14 width=58) (actual time=828.176..4757.065 rows=2865 loops=1) - Bitmap Heap Scan on datosentrada_his (cost=4329.79..4385.75 rows=14 width=58) (actual time=828.171..4748.222 rows=2865 loops=1) Recheck Cond: (((unitno)::text = '142'::text) AND ((flota)::text = 'Transportes Bueno'::text) AND (fechacreacion = '2011-07-13 05:00:00'::timestamp without time zone) AND (fechacreacion = '2011-07-15 04:59:00'::timestamp without time zone)) - BitmapAnd (cost=4329.79..4329.79 rows=14 width=0) (actual time=802.119..802.119 rows=0 loops=1) - Bitmap Index Scan on fki_vehiculo_his (cost=0.00..31.70 rows=1496 width=0) (actual time=390.128..390.128 rows=224090 loops=1) Index Cond: (((unitno)::text = '142'::text) AND ((flota)::text = 'Transportes Bueno'::text)) - Bitmap Index Scan on ind_fecha
Re: [pgsql-es-ayuda] Problema uso de indices...
Aqui esta solo el explain analyze de la seccion que comentaba alvaro, que justamente donde esta el problema: Server1 # explain analyze select * from datosentrada_his where unitno='142' and flota='Transportes Bueno' and fechacreacion between '07/13/2011 05:00' and '07/15/2011 04:59'; QUERY PLAN - Result (cost=0.00..697.42 rows=2 width=600) (actual time=80569.005..173377.349 rows=2865 loops=1) - Append (cost=0.00..697.42 rows=2 width=600) (actual time=80568.997..173364.737 rows=2865 loops=1) - Index Scan using fki_vehiculo_his on datosentrada_his (cost=0.00..697.42 rows=2 width=600) (actual time=80568.991..173356.094 rows=2865 loops=1) Index Cond: (((unitno)::text = '142'::text) AND ((flota)::text = 'Transportes Bueno'::text)) Filter: ((fechacreacion = '2011-07-13 05:00:00'::timestamp without time zone) AND (fechacreacion = '2011-07-15 04:59:00'::timestamp without time zone)) Total runtime: 173381.978 ms (6 rows) server2 # explain analyze select * from datosentrada_his where unitno='142' and flota='Transportes Bueno' and fechacreacion between '07/13/2011 05:00' and '07/15/2011 04:59'; QUERY PLAN -- Result (cost=4329.79..4385.75 rows=14 width=600) (actual time=918.279..4858.531 rows=2865 loops=1) - Append (cost=4329.79..4385.75 rows=14 width=600) (actual time=918.268..4844.345 rows=2865 loops=1) - Bitmap Heap Scan on datosentrada_his (cost=4329.79..4385.75 rows=14 width=600) (actual time=918.264..4835.848 rows=2865 loops=1) Recheck Cond: (((unitno)::text = '142'::text) AND ((flota)::text = 'Transportes Bueno'::text) AND (fechacreacion = '2011-07-13 05:00:00'::timestamp without time zone) AND (fechacreacion = '2011-07-15 04:59:00'::timestamp without time zone)) - BitmapAnd (cost=4329.79..4329.79 rows=14 width=0) (actual time=889.621..889.621 rows=0 loops=1) - Bitmap Index Scan on fki_vehiculo_his (cost=0.00..31.70 rows=1496 width=0) (actual time=364.576..364.576 rows=224090 loops=1) Index Cond: (((unitno)::text = '142'::text) AND ((flota)::text = 'Transportes Bueno'::text)) - Bitmap Index Scan on ind_fecha (cost=0.00..4298.04 rows=331110 width=0) (actual time=490.006..490.006 rows=334068 loops=1) Index Cond: ((fechacreacion = '2011-07-13 05:00:00'::timestamp without time zone) AND (fechacreacion = '2011-07-15 04:59:00'::timestamp without time zone)) Total runtime: 4863.894 ms (10 rows) Saludos Roberto Campos - 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] Problema uso de indices...
¿Qué pasa si le das un SET enable_seqscan TO off en el server 1? Ya habia hecho pruebas con el parametro enable_seqscan y ni asi me tomo en cuenta el indice, sigue haciendo lo mismo Ahora lo que paso recientemente es que el dia de hoy el server2 dejo de usar el indice al igual que el server 1.. y cuando hice pruebas en el explain analyze vi esto entre parentesis (never executed) al final de la lines del indice, no se a que se deba esto. El explain fue el siguiente: explain analyze select * from datosentrada_his where fechacreacion between '07/12/2011 05:00' and '07/13/2011 04:59' and (flota='hesa' and unitno='9014'); QUERY PLAN -- Result (cost=4932.34..5988.53 rows=265 width=600) (actual time=27.099..27.099 rows=0 loops=1) - Append (cost=4932.34..5988.53 rows=265 width=600) (actual time=27.095..27.095 rows=0 loops=1) - Bitmap Heap Scan on datosentrada_his (cost=4932.34..5988.53 rows=265 width=600) (actual time=27.093..27.093 rows=0 loops=1) Recheck Cond: (((unitno)::text = '9014'::text) AND ((flota)::text = 'hesa'::text) AND (fechacreacion = '2011-07-12 05:00:00'::timestamp without time zone) AND (fechacreacion = '2011-07-13 04:59:00'::timestamp without time zone)) - BitmapAnd (cost=4932.34..4932.34 rows=265 width=0) (actual time=27.089..27.089 rows=0 loops=1) - Bitmap Index Scan on fki_vehiculo_his (cost=0.00..1403.11 rows=54548 width=0) (actual time=27.086..27.086 rows=0 loops=1) Index Cond: (((unitno)::text = '9014'::text) AND ((flota)::text = 'hesa'::text)) - Bitmap Index Scan on ind_fecha (cost=0.00..3528.85 rows=168081 width=0) (never executed) Index Cond: ((fechacreacion = '2011-07-12 05:00:00'::timestamp without time zone) AND (fechacreacion = '2011-07-13 04:59:00'::timestamp without time zone)) Total runtime: 27.214 ms (10 rows) Debería cambiar al segundo plan. Si es así, creo que lo que deberías hacer es 1. incrementar effective_cache_size 2. incrementar cpu_tuple_cost y/o cpu_operator_cost El effective_cache_size lo tengo a 3/4 de mi memoria ram no se si sea recomendable aumentarlo mas. Los otros 2 parametros no los he movido hare pruebas a ver que pasa. Entre mis pruebas hice un indice con los 3 campos involucrados en la consulta y aunque postgres deberia tomar el indice1 donde estan los 2 primeros campos y el indice2 donde esta la fecha. Al crear este nuevo indice ya esta funcionando mejor la consulta pero creo que ya son demasiados indices sobre una tabla.. y los 2 primeros indices si se estan usando espero no me afecte el desempeño tanto indice, ustedes que creen?. Saludos y muchas gracias por sus comentarios y ayuda. Roberto Campos -- Álvaro Herrera alvhe...@alvh.no-ip.org - 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] Ayuda Consulta de fechas
El 27/07/11, Alvaro Herrera alvhe...@alvh.no-ip.org escribió: Excerpts from motum hesa's message of mar jul 26 19:36:37 -0400 2011: Ojo que si usas mucho el campo fecha por separado y buscas por rangos de fechas, puede que no te resulte bueno eliminar ese índice. La razón es que un índice de múltiples columnas es más pesado que uno de una sola columna (obvio). Me ha tocado ver casos en los que existían ambos índices (uno con la columna sola y otro con dos columnas), se borró el de la columna sola, y resultó que era tan utilizado antes de borrarse que el sistema se puso mucho más lento. Así que te sugiero que si vas a hacer esto, le pongas atención al sistema para ver si es verdad que mejora al borrar el índice. Borre el indice he hice pruebas, si se usaba ese indice asi que lo tuve que crear otra vez, aunque con eso me di cuenta que el otro indice que incluia la fecha al parecer no me sirve, lo elimine y no vi cambios hasta el momento. De todas maneras seguire checando por cualquier cosa. Hmm. Honestamente suena a que el campo debería eliminarse completamente :-) Quizás esta propiedad debería almacenarse en otra tabla, si es que realmente es necesario almacenarla. A todo esto, a veces cuando tienes campos que tienen muchos valores nulos, te puede convenir crear un índice de esta forma: create index fff on tutabla (viajeactivo) WHERE viajeactivo IS NOT NULL; Haciéndolo así ahorras espacio en el índice y no pierdes ninguna funcionalidad (a menos que hagas búsquedas WHERE viajeactivo IS NULL). La columna viajeactivo es una referencia a otra tabla, lo por lo que me di cuenta que me hace falta una llave foranea ahi, ya lo platique con los programadores ya que esto les pega y en la primera oportunidad lo hago. Como son demasiados registros tarda mucho cambiar las columnas pero ya estoy agregando la propiedad NOT NULL a la mayoria de los campos. Aunque parece que voy a tardar un buen rato. Sí, mi hipótesis es que eso debería ayudar en el group by. No ayudo el indice que me dijiste para el Group by. Lo que te puedo decir es que el optimizador sabe convertir MIN() y MAX() en un indexscan con LIMIT 1 internamente, pero estos trucos sólo se pueden aplicar en situaciones limitadas. [leyendo código] En particular, por lo que veo en el código, no se pueden aplicar cuando tienes GROUP BY ... así que olvida lo que dije de ese índice, porque es obvio que no te va a servir. Puedes mirar el código fuente (con bastantes comentarios que explican lo que puede y lo que no puede hacer) acá: Leyendo el codigo entendi todo lo que me decias y pues cambie la consulta a que se consulte cada unidad por separado en vez de todas las unidades, con eso quite el group by y use el limit y por cada unidad tarda algunos milisegundos.. haciendo cuentas cada flota tiene aprox 100 unidades multiplicando esto por los milisegundos que tarda cada unidad resulta mas rapido hacer un ciclo en programación que consulte cada unidad de la flota.. por lo que se harian 100 consulta con el limit 1... Aqui el indice que sugeriste ayudo bastante. Muchas gracias. (Este es el de 9.0. Si estás usando otra versión tendrás que buscar el mismo archivo a partir de otro HEAD). Para opciones de repliacion planeadas mas adelante voy a pasarme a la version 9 de postgres ( ahorita estoy en la 8.4), crees que ayude tambien a las consultas? -- Álvaro Herrera alvhe...@alvh.no-ip.org Muchas gracias por todos tus comentarios Álvaro ayudaron bastate a resolver dudas y mejorar mi tabla. Felicitaciones a los programadores el codigo esta muy explicito y excelentemente bien comentado. Para la Lista mi solucion sera cambiar de una Consulta sobre todos los registros con Group by a varias consultas pequeñas y rapidas por unidad sin group by. Saludos Roberto Campos - 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] Ayuda Consulta de fechas
Como comentario adicional ya llevo 2 semanas con particionamiento 2 particiones llenas y una comenzo hoy... haciendo pruebas si mejoro la consulta inicial en muchos segundos... detalles como activar el parametro constrain_exclusion y crear los indices me hicieron darme de topes un rato pero yo creo que igualmente en produccion creare las particiones, aqui al ser tablas que ya no se van a modificar convendria usar indices con clustered? Ten presente que puedes agregar restricciones NOT NULL a varios campos de una tabla a la vez, no tienes por qué ir de uno en uno: alvherre=# create table motum (a int, b int); alCREATE TABLE alvherre=# alter table motum alter a set not null, alter b set not null; ALTER TABLE alvherre=# \d motum Tabla «public.motum» Columna | Tipo | Modificadores -+-+--- a | integer | not null b | integer | not null Gracias eso no lo sabia... Sí, por eso me gusta trabajar en este código. Hablando de trabajar, alguna manera de contribuir al proyecto en mis pocos tiempos libres, soy pogramador, traductor, intento ser DBA... y pues lo que pueda ayudare... -- Álvaro Herrera alvhe...@alvh.no-ip.org Saludos Roberto Campos - 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] Ayuda Consulta de fechas
Hola Alvaro, gracias por responder, Estoy tratando de checar todo lo que me comentaste, mas o menos como sigue Creo que parte del problema es que los índices no están bien escogidos. La lista es la siguiente: datosentrada_his_pk PRIMARY KEY, btree (importacionid) fki_importacionid_his btree (importacionid) fki_vehiculo_his btree (unitno, flota) fki_viajeactivo_his btree (viajeactivo) ind_fecha btree (fechacreacion DESC) inf_fecha_id_his btree (fechacreacion, importacionid) El índice fki_importacionid_his no sirve para nada porque la llave primaria ya creó un índice en ese mismo campo. Te sugiero borrarlo. Hoy lo borro El índice ind_fecha es redundante con inf_fecha_id_his. A menos que se uso mucho, te sugiero borrarlo también. Hago notar que un índice se puede recorrer en ambas direcciones, así que tener uno ASC y uno DESC no aporta en nada. Te sugiero borrar ind_fecha. Si tengo muchas consultas solo por la fecha, buscando pues uso menos el segundo indice el cual pues intentare borrar para ver que pasa. de hecho casi siempre busco una fecha para obtener el valor del campo importacionid El índice fki_viajeactivo_his suena bastante sospechoso, pero habría que saber qué hace el campo viajeactivo antes de dar una opinión. El campo viajeactivo, hace referencia a otra tabla que es donde se guardan los viajes realizados por una unidad por ejemplo, salio de base tal dia con tales valores y regreso tal dia con tales valores, en la tabla en cuestion datosentrada_his se hace referencia a viajeactivo en el momento que llegaron los datos para cuando se quiera hacer el analisis del viaje o si se quiere hacer un analisis solo por fecha. Ninguno de estos cambios haría nada para mejorar esta consulta, pero sí debería ayudar a que el sistema sea un poco menos lento en términos generales. Ok.. eso ayudara mucho.. gracias Para mejorar esta consulta creo que deberías tener un índice en (unitno, flota, fechacreacion). Agrégalo y prueba de nuevo la consulta a ver si lo usa. Voy a crear el indice que mencionas aunque precisamente las consultas lentas no incluyen unidad, pero es posible que ayude con el group asi k lo hare hoy en la noche. gracias nuevamente. Ya mencionaste que has hecho modificaciones en una BD que escribió otra persona, sin cambiar los campos de las tablas. Yo te recomendaría bastante que trataras de hacer una mejora en el diseño moviendo columnas de manera que tu diseño sea normal (como en forma normal). Ok.. por su puesto que hare caso a esa recomendacion aunque no lo puedo hacer rapido ya que voy a tener un problema con los programadores.. jejeje.. trabajan hibernate y pues van a repelar.. mientras tanto tratare de hacer un diseño mejor de esa tabla usando la forma normal. Gracias nuevamente por constestar.. ya te comentare que pasa con los cambios. -- Álvaro Herrera alvhe...@alvh.no-ip.org Mientras tanto te comento que las consultas mas lentas son donde uso las funciones MAX y MIN... el indice que me comentas ayudara... o tienes alguna recomendacion mas para usar este tipo de funciones. ? Saludos Roberto Campos - 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] Ayuda Consulta de fechas
Disculpen el reenvio, pero ya no recibi respuesta y no se si llego el correo, solo lo reenviare esta vez por si las dudas. Entre tanto les comento que probe la consulta en otra tabla con menos campos pero igual mas de (50 millones de registros)... en la cual no tengo ningun campo en nulo (pos si afectaba). y pasa exactamente lo mismo, hago la consulta con fechas entre 1 mes.. y tarda demasiado tiempo en traer datos ( mas de 5 minutos), pense que solo era en fechas pero tambien pasa en el id de la tabla ( importacionid) , se que postgresql soporta bases de datos mucho mas grandes a la que estoy manejando y supongo debe haber una forma de hacer mas rapidas estas consultas. De verdad necesito su ayuda ya que yo recomende ampliamente postgresql y ya me estan diciendo que debi seleccionar otro manejador de BD (llegue al proyecto como consultor y desarrollador de sistemas embebidos y ahora soy el DBA entre otras cosas). Saludos. Roberto Campos P.D. Ya comence con pruebas de particionamiento y aunque apenas llevo 2 particiones no he notado mejoria en la consulta que les presente. Aunque si en otro tipo de consultas que no requieren agrupación. El día 22 de julio de 2011 20:41, motum hesa mot...@gmail.com escribió: Alvaro una disculpa quise editar la consulta para que se viera mas rapido el tipo de campo.. pero ahora que les mande la estructura pues ya no es necesario Hmm, aquí no hay ninguna columna idtbl. Por favor muestra la consulta y el explain analyze con los nombres correctos de las columnas, sin editorialización. Esta es la consulta original, ahorita cambio el tiempo que muestra el explain debido a las fechas por las que voy. select max(importacionid), min(importacionid), unitno, flota from datosentrada_his where fechacreacion BETWEEN '2011-06-01 00:00:00' and '2011-07-01 23:59:59' group by unitno,flota order by unitno Sort (cost=969443.39..969445.32 rows=775 width=18) Sort Key: unitno - HashAggregate (cost=969394.57..969406.19 rows=775 width=18) - Index Scan using ind_fecha on datosentrada_his (cost=0.00..925042.61 rows=4435196 width=18) Index Cond: ((fechacreacion = '2011-06-01 00:00:00'::timestamp without time zone) AND (fechacreacion = '2011-07-01 23:59:59'::timestamp without time zone)) El día 22 de julio de 2011 18:08, Jaime Casanova ja...@2ndquadrant.com escribió: On Fri, Jul 22, 2011 at 5:16 PM, motum hesa mot...@gmail.com wrote: Table public.datosentrada_his Column | Type | Modifiers -+-+--- aunque no es lo que preguntaste, te dire que tanto campo que acepta NULL me huele a mal diseño (especialmente porque hay campos que obviamente estan relacionados entre si de forma especial Hola Jaime, gracias por el comentario, efectivamente el sistema tenia un mal diseño de base de datos cuando lo tome, yo he tratado de mejorarlo con indices, llaves primarias y foraneas en donde debe ser, trato de evitar la insercción de nullos en los campos que viste pero no he cambiado la estructura, si es recomendable hoy mismo lo hago en los campos que ya estoy seguro que no hay nullos... -- Jaime Casanova www.2ndQuadrant.com Professional PostgreSQL: Soporte 24x7 y capacitación Alvaro Herrera Sí, hay varias cosas que son sospechosas en este diseño ... pareciera una tabla donde se almacenan detalles crudos (posición geográfica en un momento determinado) junto con detalles cocinados (análisis a partir de la historia del movimiento del vehículo). Eso deberías evitarlo, porque crea todo tipo de problemas. de hecho todo esos datos ya fueron procesados y son guardados como historicos en esta tabla. Aunque si me puedes decir algun tipo de problemas que tu consideres se presente en este diseño de tabla lo tomare en cuenta para una posible reestructuracion... Saludos y gracias por sus consejos, siempre son bienvenidos... Roberto Campos - 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] Ayuda Consulta de fechas
Hola ya habia contestado pero no me fije que se fue a borradores el correo, pero bueno disculpen la demora... aqui esta la salida del comando: Muestra el \d de la tabla y qué índices tiene. -- Álvaro Herrera alvhe...@alvh.no-ip.org Table public.datosentrada_his Column|Type | Modifiers -+-+--- fechaentrada| timestamp without time zone | lat | double precision| lng | double precision| direccion | character varying | entrandosaliendo| integer | odometrototal | double precision| hrastotalmotor | double precision| hrastotalpto| double precision| hrastotalralenti| double precision| combustotalralenti | double precision| combustotalpto | double precision| bateria | double precision| altitud | double precision| factorcarga | double precision| torque | double precision| conexiontrailer1| integer | conexiontrailer2| integer | refpunto| integer | refciudad | integer | unitno | character varying(15) | not null flota | character varying(40) | not null importacionid | bigint | not null viajeactivo | integer | cro | integer | ignicion| boolean | pia | integer | fechaenvio | timestamp without time zone | fechacreacion | timestamp without time zone | point_geom | geometry| point_geomutm | geometry| combustibletotal| double precision| dkilometros | double precision| dhoraspto | double precision| dhorasmotor | double precision| dcombustible| double precision| velpromedio | double precision| dhorasralenti | double precision| default 0 nalarmas| smallint| default 0 nfallas | smallint| default 0 nmensajes | smallint| default 0 tempmotor | double precision| tempaceite | double precision| presionturbo| double precision| presionaceite | double precision| rpm | integer | tiempo_optimas_rpm | double precision| default 0 tiempo_retarder | double precision| default 0 dcombustibleralenti | double precision| dcombustiblepto | double precision| dtiempo_optimas_rpm | double precision| dtiempo_retarder| double precision| mrefp | double precision| mrefc | double precision| pendientes | smallint| pos_gps | boolean | minrpm | integer | engrane_transmision | integer | vel_max | double precision| compre_break_dis| double precision| cont_apli_fren | integer | cont_ace_brusca | integer | cont_desac_brusca | integer | total_eng_cruise| double precision| odom_virtual| double precision| num_sate| integer | vel_gps | integer | edobatt | smallint| default 2 Indexes: datosentrada_his_pk PRIMARY KEY, btree (importacionid) fki_importacionid_his btree (importacionid) fki_vehiculo_his btree (unitno, flota) fki_viajeactivo_his btree (viajeactivo) ind_fecha btree (fechacreacion DESC) inf_fecha_id_his btree (fechacreacion, importacionid) Check constraints: enforce_dims_point_geom CHECK (ndims(point_geom) = 2) enforce_dims_point_geomutm CHECK (ndims(point_geomutm) = 2) enforce_geotype_point_geom CHECK (geometrytype(point_geom) = 'POINT'::text OR point_geom IS NULL) enforce_geotype_point_geomutm CHECK (geometrytype(point_geomutm) = 'POINT'::text OR point_geomutm IS NULL) enforce_srid_point_geom CHECK (srid(point_geom) = 4326) enforce_srid_point_geomutm CHECK (srid(point_geomutm) = 32614) Foreign-key constraints: historico_vehiculo FOREIGN KEY (unitno, flota) REFERENCES vehiculos(unitno, flota) ON UPDATE CASCADE Triggers: pdatosentrada_his_trig
Re: [pgsql-es-ayuda] Ayuda Consulta de fechas
Alvaro una disculpa quise editar la consulta para que se viera mas rapido el tipo de campo.. pero ahora que les mande la estructura pues ya no es necesario Hmm, aquí no hay ninguna columna idtbl. Por favor muestra la consulta y el explain analyze con los nombres correctos de las columnas, sin editorialización. Esta es la consulta original, ahorita cambio el tiempo que muestra el explain debido a las fechas por las que voy. select max(importacionid), min(importacionid), unitno, flota from datosentrada_his where fechacreacion BETWEEN '2011-06-01 00:00:00' and '2011-07-01 23:59:59' group by unitno,flota order by unitno Sort (cost=969443.39..969445.32 rows=775 width=18) Sort Key: unitno - HashAggregate (cost=969394.57..969406.19 rows=775 width=18) - Index Scan using ind_fecha on datosentrada_his (cost=0.00..925042.61 rows=4435196 width=18) Index Cond: ((fechacreacion = '2011-06-01 00:00:00'::timestamp without time zone) AND (fechacreacion = '2011-07-01 23:59:59'::timestamp without time zone)) El día 22 de julio de 2011 18:08, Jaime Casanova ja...@2ndquadrant.com escribió: On Fri, Jul 22, 2011 at 5:16 PM, motum hesa mot...@gmail.com wrote: Table public.datosentrada_his Column | Type | Modifiers -+-+--- aunque no es lo que preguntaste, te dire que tanto campo que acepta NULL me huele a mal diseño (especialmente porque hay campos que obviamente estan relacionados entre si de forma especial Hola Jaime, gracias por el comentario, efectivamente el sistema tenia un mal diseño de base de datos cuando lo tome, yo he tratado de mejorarlo con indices, llaves primarias y foraneas en donde debe ser, trato de evitar la insercción de nullos en los campos que viste pero no he cambiado la estructura, si es recomendable hoy mismo lo hago en los campos que ya estoy seguro que no hay nullos... -- Jaime Casanova www.2ndQuadrant.com Professional PostgreSQL: Soporte 24x7 y capacitación Alvaro Herrera Sí, hay varias cosas que son sospechosas en este diseño ... pareciera una tabla donde se almacenan detalles crudos (posición geográfica en un momento determinado) junto con detalles cocinados (análisis a partir de la historia del movimiento del vehículo). Eso deberías evitarlo, porque crea todo tipo de problemas. de hecho todo esos datos ya fueron procesados y son guardados como historicos en esta tabla. Aunque si me puedes decir algun tipo de problemas que tu consideres se presente en este diseño de tabla lo tomare en cuenta para una posible reestructuracion... Saludos y gracias por sus consejos, siempre son bienvenidos... Roberto Campos - 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] Ayuda Consulta de fechas
Hola a menos que me equivoque no vi en los archivos que revise de la lista que trataran este tema, Tengo la siguiente consulta select nombre, tipo, max(idtbl) , min(idtbl) from tabla_grande where fechacreacion between '2011-07-01 05:00:00' and '2011-07-21 04:59:00' group by nombre, tipo order by nombre El problema es que tarda demasiado en traerme datos, y pues solo quiero el max y el min, le hice un explain y me arrojo lo siguiente. Sort (cost=432277.66..432377.66 rows=4 width=18) Sort Key: public.tabla_grande.nombre - HashAggregate (cost=428620.12..429220.12 rows=4 width=18) - Append (cost=0.00..410897.41 rows=1772271 width=18) - Index Scan using ind_fecha on tabla_grande (cost=0.00..410897.41 rows=1772271 width=18) Index Cond: ((fechacreacion = '2011-07-01 05:00:00'::timestamp without time zone) AND (fechacreacion = '2011-07-12 04:59:00'::timestamp without time zone)) Para arreglarlo estuve buscando en la red y encontre que podria usar indices tipo GIST para consultas con fechas pero no encontre ningun ejemplo. Mas datos sobre mi hardware y software: 2 QUAD XEON 6 GB RAM 4 x 150GB 10KRPM SATA en RAID 10 Freebsd 64 bits Postgres 8.4.7 tuneado para este server con ayuda de la lista ( gracias nuevamente ayudo mucho al desempeño general) tabla_grande mas de 50 millones de registros y cada dia crece 1/2 millon mas Otra de las opciones es agregar particionamiento a esa tabla... ya lo hice esta semana y pues espero probar para checar resultados. Saludos y de antemano gracias por su ayuda. Roberto Campos - 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] Hardware para mejor funcionamiento de PostgreSQL
Finalmente después de mucho optimizar PostgreSQL y software se ha decidido mejorar el hardware. Así que les pido su opinión sobre lo siguiente: FreeBSD x64 Dual Xeon 2.13Ghz Nehalem 6 GB RAM 1 disco de 500GB SATA o 2 Discos de 300GB Velociraptor 10k RPM RAID 1 También nos ofrecen 4 HDD de 150GB 10K en RAID 10 ¿Cuál sería la mejor opción en HDD? ¿Qué mas recomiendan para que PostreSQL esté contento con el hardware?. Gracias. - 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] Hardware para mejor funcionamiento de PostgreSQL
La opcion que tambien se me ocurre es un disco de 500 para SO y logs y un array ya sea RAID 1 o 10 para la bd, que opinan? El jun 8, 2011 9:51 a.m., Miguel Angel Hernandez Moreno miguel.hdz@gmail.com escribió: saludos Yo siempre opto pro el RAID 10, ya que en performance es mejor la escritura para postgres, solo que esta el detalle que te kita bastasnte espacio, pero ahi va una cosas por otra. Pero ya depende de cuanto espacio vallas a requerir, has tus cuentas y escoge el mejor de los procesadores los Xeon son buenos y 6 GB de ram tambien me parece bien El 8 de junio de 2011 09:40, motum hesa mot...@gmail.com escribió: Finalmente después de mucho optimizar PostgreSQL y software se ha decidido mejorar el hardware... - 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 -- ISC Miguel Angel Hernandez Moreno
Re: [pgsql-es-ayuda] Hardware para mejor funcionamiento de PostgreSQL
Pero con los datos que das, yo en principio optaría por el RAID 10 por tener más spindles, pero depende de si luego vas a necesitar ampliar capacidad y te vas a quedar sin slots de disco. El procesador y la RAM de verdad no me atrevo a opinar sin conocer el uso que va a tener la máquina. La base de datos pesa +20 GB y se cuenta con 5 programas escritos en Java que estarán durante todo el día haciendo consultas, inserts updates y demás. Además de 1 aplicación web (JSP servidor Glassfisg 2.1) que también realiza modificaciones a la base de datos. P.D. De tu email deduzco que optas por no optimizar postgres (o no optimizarlo más) y comprar hardware nuevo. No es mala opción nunca tener mejor hardware (si hay presupuesto), pero esto no garantiza mayor rendimiento, porque tal vez el problema está en otro sitio... PostreSQL se seguirá optimizando, así mismo el software se seguirá optimizando. Con el problema anterior se hicieron muchas pruebas y aunque el consumo si se logró bajar el hardware no da para más.. Las pruebas las puedes encontrar en la lista con el asunto PostgreSQL consumo de CPU - 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] Particiones y funciones
El día 26 de mayo de 2011 11:29, Jaime Rivera jriv...@ende.bo escribió: Si se puede, si es que llenas tus tablas partiocionadas a través de un trigger, la misma función del trigger puede crear la tabla para el siguiente mes en caso de ser necesario. Ok, gracias mi duda es si el trigger se autoactualizar para redirigir los registros hacia esa nueva tabla. - 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] PostgreSQL consumo de CPU
Aparte de lo que han comentado los compañeros: a) Yo miraria en iostat y en top que estan haciendo los postgres. Si estan en iowait (en top), tienes demasiada carga en los discos duros. b) Como has creado las tablas? Que tipo carga de trabajo tienen? Mayoritariamente Selects o Inserts, updates y deletes? Depende de como lo uses habra que configurarlos. c) Creaste las tablas de forma automatica con una herramienta (hibernate, p.ej.) o a mano. Si es con una herramienta automatica, asegurate que te ha creado todos los indices que necesitas. d) En vez de un vacuum analyze, yo activaria autovacuum analyze y ejecutaria cluster en las tablas de mas uso por el indice de mas uso (apagando antes las aplicaciones para que no bloqueen la tabla) de vez en cuando. Mira la documentacion por que 'cluster' necesita espacio de disco para funcionar. e) Si no recuerdo mal, en la version 8.4 pusieron demasiado altas las veces que realiza un analyze para tomar estadisticas, yo tambien lo reduciria. f) Usas muchas funciones agregadas? Todas las consultas incluyen un order by? Dependiendo del tipo de consultas (selects) que hagas la configuracion tambien cambiara. g) Pasate por la lista de correo de freebsd-es. Igual alli te orientan mejor sobre como configurar el sistema. Gracias por contestar. En el top los procesos aparecen en RUN. Por lo demás lo estaré revisando y ya contaré como ha ido todo. Gracias a todos. - 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] PostgreSQL consumo de CPU
Que tal. He cambiado el max_prepared_transacions a 0. Por ahora postgres con los valores que me han recomendado si ha bajado su consumo de CPU pero igualmente no es el deseado. Estaremos probando como sigue el consumo con la nueva config. Alguna otra recomendación?. Gracias - 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] PostgreSQL consumo de CPU
Sí se utilizan, se cambió el valor solo por recomendación y ver si realmente afecta o no el consumo de cpu de postgres. Si la optimización de PostgreSQL no ayudará mucho en el consumo de CPU, ¿qué otras cosas recomiendan hacer?. Muchas gracias! - 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] PostgreSQL consumo de CPU
Que tal. Actualmente contamos con un servidor (Intel Xeon Dual, 2 GB de RAM, RAID 1 SATA 320 GB - FreeBSD 8 32 bits) con PostgreSQL 8.4.5. Pero tenemos el problema de que postgres está consumiento el 100% de CPU lo que genera un mal rendimiento en las aplicaciones web. Hemos notado que esto se debe a 3 aplicaciones que se conectan (realizan inserts, updates, etc) a la base de datos (no abren más de 30 conexiones) así que se optimizaron, además de que también se optimizó PostgreSQL con los siguientes valores: max_connections = 100 shared_buffers = 512MB max_prepared_transactions = 100 work_mem = 10MB maintenance_work_mem = 256 MB checkpoint_segments = 64 effective_cache_size = 768 MB max_locks_per_transaction = 128 Ya se realizó vacuum analyze además de que se activó el autovacuum para las tablas con más carga de actualización. Si ha tenido un efecto en el consumo de CPU pero no el deseado. Cabe mencionar que localmente se cuenta con un servidor con las mismas aplicaciones y versión de postgres con la única diferencia que tiene 4GB de RAM (FreeBSD 8 64 bits) y Postgres trabaja correctamente. ¿Se debería aumentar la memoria RAM del servidor contratado? ¿Disminurá esto el consumo de CPU? ¿Qué otras opciones recomiendan?. Gracias - 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] PostgreSQL consumo de CPU
Marcos Ortiz: Muchas gracias por las guías y recomendaciones, las estaré leyendo y probando para ver si noto alguna diferencia. En donde puedo ver la charla Whackamole?. Gracias. Jaime Casanova: En las aplicaciones que manejamos si se utilizan transacciones preparadas. Ya estaré probando las opciones que me dijiste que cambiara. Gracias - 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: Re: [pgsql-es-ayuda] Replicar datos sin IP FIJA
Ok... muchas gracias por los comentarios, pues miren vamos a probar 2 alternativas ( dejando la VPN como reserva ya que suena buena idea): 1.- Realizar un webservice en JAVA que se encargue de pasar los objetos relacionados a las tablas para descargarlos directamente poniendo del lado del server un pool de conexiones y un administrador de carga para soportar varias conexiones y del lado del cliente descargando la informacion a postgres. 2.- Al mismo tiempo desarrollare un programa de conexion por sockets en el cual con un pequeño protocolo que desarrolle hace un par de años podria enviar la informacion haciendo que el cliente se conecte con un programita de sockets que voy a poner a en el servidor con IP fija, asi no importara la ip que tenga el cliente, de todas maneras necesitaria un programa cliente. nuevamente agradesco todos sus comentarios en verdad ayudan mucho... espero tener pronto algo funcionando y si puedo comentare el resultado. Saludos El día 19 de febrero de 2010 13:08, Jonathan Finlay jmfinl...@gmail.com escribió: ¿¿?? Ciertamente si hace una VPN lo que debería hacer es conectar el nodo con IP variable a la VPN, y por lo tanto no necesita tener un dyndns o equivalente. En mi experiencia, usar dyndns para una cosa como esta es frágil y complicado. Es cierto y yo preferiría una VPN sin duda alguna, pero esto dependería de las circunstancias, no se puede negar que es una alternativa viable y dependerá de las posibilidades que tenga para realizar una u otra configuración, tomando en cuenta que la que yo doy no es la más segura pero es la mas rápida. Y en mi experiencia no he tenido problemas con dns dimamicos y este tipo de configuración en los tiempos de la universidad en unos experimentos de aplicaciones distribuidas y se registran de vez en cuando errores de timeout. -- Jonathan. -- Jonathan. -- TIP 3: Si encontraste la respuesta a tu problema, publícala, otros te lo agradecerán
Re: Re: [pgsql-es-ayuda] Replicar datos sin IP FIJA
Hola gracias por todos los comentarios.. una de las ideas era realizar el replicador con webservices, estuve leyendo sobre VPN y suena una buena opcion y pues al parecer implementare los webservices y cuando tenga mas experiencia en las VPN le dare por ahi... k por cierto me gusto OPENVPN.. pero no lo vi para FreeBSD, tendre que buscarle mas. El día 18 de febrero de 2010 11:59, Jonathan Finlay jmfinl...@gmail.com escribió: Por que no configuras un puerto en tu router o en tu firewall para hacer forwarding hacia la maquina a donde vas a replicar la base de datos y ya. Esto ultimo tendria el inconveniente de que cada vez k la maquina con ip dinamica cambiara tendria que esta cambiando la configuracion, no me suena buena idea, pero tal vez eres experto en eso y hay algo k no sepa k me puedas comentar. gracias -- Jonathan. -- TIP 10: no uses HTML en tu pregunta, seguro que quien responda no podrá leerlo
Re: [pgsql-es-ayuda] Replicar datos sin IP FIJA
El día 17 de febrero de 2010 15:31, Alvaro Herrera alvhe...@alvh.no-ip.org escribió: motum hesa escribió: Hola he probado SLONY para replicar datos de postgres y me ha funcionado perfectamente... sin embargo ahora me encuentro con el problema de que la replicación tiene que hacerse desde un lugar distante y por lo que cheque no puedo usar un dns para hacer la replicacion y pues no tengo una IP FIJA, alguien sabe de alguna herramienta que pueda ayudarme. Usa una VPN. Hola perdona la ignoracia, pero con la VPN no necesito tener IP fija en los 2 lados? Con SLONY puedo hacer la replicacion con la VPN? si tienen algo de info para empezar se los agradecere. -- Alvaro Herrera Vendo parcela en Valdivia: http://rie.cl/?a=255568 El conflicto es el camino real hacia la unión -- TIP 3: Si encontraste la respuesta a tu problema, publícala, otros te lo agradecerán
[pgsql-es-ayuda] Replicar datos sin IP FIJA
Hola he probado SLONY para replicar datos de postgres y me ha funcionado perfectamente... sin embargo ahora me encuentro con el problema de que la replicación tiene que hacerse desde un lugar distante y por lo que cheque no puedo usar un dns para hacer la replicacion y pues no tengo una IP FIJA, alguien sabe de alguna herramienta que pueda ayudarme. Otra cosa que estoy comenzando a plantear es la posibilidad de hacer una replicación con web services, pero todavia no tengo bien definido esto, si alguien tiene algun comentario o sugerencia, se los agradecere mucho. Gracias a todos de antemano por su respuesta, Motums -- TIP 7: no olvides aumentar la configuración del free space map
Re: [pgsql-es-ayuda] Inserccion muy lenta a una base de datos
Mcuhas gracais por tu respuesta fernando, pues hice varias cosas, mejore los indices, y pues le subimos al pool de conexiones, con eso mejoro mucho la inserccion y pues voy a checar lo de la actualización a postgres 8.3 uso postgis me imagino que tendre que buscar tambien la libreria correcta para la version que traiga el 8.3.. Saludos y nuevamente gracias por tu respuesta -- TIP 9: visita nuestro canal de IRC #postgresql-es en irc.freenode.net
Re: [pgsql-es-ayuda] Inserccion muy lenta a una base de datos
Hola disculpa la tardanza.. por error mande la respuesta a borrador en vez de enviarla por correo y hasta ahorita me di cuenta El primer paso es determinar dónde está el cuello de botella: ¿CPU o discos? Monitorea tu sistema y confirma qué valores se disparan al momento que notas las transacciones muy lentas. De todas maneras, los síntomas descriptos sugieren problemas de concurrencia con checkpoints. Comentanos qué versión de Postgres estás utilizando, como está configurado (shared_buffers, checkpoints, synchronous_commit) y la naturaleza de tu hardware, en especial el I/O, y el sistema operativo. Postgres 8.2.9 ( con postgis 1.3.2 ) .- Tengo un sistema en JAVA que usa esas mismas librerias, espero actualizar este año. En cuanto a la configuración es la siguiente: shared_buffers = 24MB Sobre Checkpoitns no tengo ninguna configuración por desgracia desconosco del tema pero ya comence a investigar.. te agradeceria si tienes info sobre esto. Por lo tanto no tengo activado el WAL ( o mas bien todo lo referente a eso esta comentado) En cuanto al Hardware tengo: AMD de 2 nucleos a 2GHZ 3 GB de memoria ram 1 disco SATA de 160GB a 7200rpm SO: SLACKWARE 11 GLASSFISH 2 ( como servidor de paginas web) Comento que este servidor es de pruebas por que ahorita solo atiende a 20 dispositivos la idea original era que soportara 100 y de ahi a mejorar el hardware. Antes de hacer cambios debes confirmar que este sea el problema, para lo cual según la versión de Postgres que corras dispones de distintas herramientas. Te recomiendo vayas leyendo la guía de Greg Smith: http://www.westnet.com/~gsmith/content/postgresql/chkp-bgw-83.htm He leido el documento y me parece muy interesante y aunque trae cosas para la version 8.2 casi todo es para la version 8.3 aqui tengo un dilema entre buscar mas para la version que tengo o intentar actualizar ( esperando no colapse mi sistema por las librerias que uso en JAVA ) Saludos, Fernando. Saludos y gracias por la respuesta. -- TIP 4: No hagas 'kill -9' a postmaster
[pgsql-es-ayuda] Inserccion muy lenta a una base de datos
Tengo un sistema al que inserto datos periodicos cada 10 segundos, por la forma en que esta diseñado todo esas insercciones pueden ser 1 o 2 hasta 120, son datos binarios que se traducen en información leible con un programita en java, cuando todo esta normal los datos se traducen y se insertan en la base de datos casi inmediatamente, pero en algunas ocaciones cuando hay muchos datos pendientes, resulta que la inserccion en la misma base de datos llega a tardar has 1 min por dato a insertar ( cada vez que inserto se disparan varios triggers en la base de datos) despues de unas horas ya que se tradujeron todos los pendientes todo vuelve a la normalidad y se traducen los datos como antes ( 1 dato normalmente se tarda de 1 o 3 segundos en traducirce ), Mi pregunta especificiamente es: ¿Hay alguna manera de saber por que se alenta la inserccion? Se que pueden ser los triggers pero la verdad son varios y no se hay alguna manera de checar cual es el que se esta atorando, gracias por todo de antemano... Saludos Motum -- TIP 1: para suscribirte y desuscribirte, visita http://archives.postgresql.org/pgsql-es-ayuda
[pgsql-es-ayuda] problema: FATAL: role postgres is not permitted to log in
Hola... creé un nuevo usuario en pgadmin III y funciono sin problemas, este usuario solo tiene permisos para ver una base de datos, pero resulta que al intentar entrar con el usuario postgres nuevamente me manda el siguiente problema: FATAL: role postgres is not permitted to log in ya cheque el pg_hba y reinicie el server para cargar otra configuracion y nada.. no puedo entrar a mis bases de datos.. solo a verlas con el nuevo usuario. Hay alguna manera de restablecer el permiso para el usuario postgres? Saludos y de antemano gracias por sus aportaciones... -- TIP 1: para suscribirte y desuscribirte, visita http://archives.postgresql.org/pgsql-es-ayuda
Re: [pgsql-es-ayuda] problema: FATAL: role postgres is not permitted to log in
Investigando un poco mas en mis configuraciones al parecer el problema es que no permite que me logge como postgres... como le reactivo esto? o si alguien cree que es otra cosa con gusto acepto propuestas... Saludos El día 7 de diciembre de 2009 13:08, motum hesa mot...@gmail.com escribió: Hola... creé un nuevo usuario en pgadmin III y funciono sin problemas, este usuario solo tiene permisos para ver una base de datos, pero resulta que al intentar entrar con el usuario postgres nuevamente me manda el siguiente problema: FATAL: role postgres is not permitted to log in ya cheque el pg_hba y reinicie el server para cargar otra configuracion y nada.. no puedo entrar a mis bases de datos.. solo a verlas con el nuevo usuario. Hay alguna manera de restablecer el permiso para el usuario postgres? Saludos y de antemano gracias por sus aportaciones... -- TIP 6: ¿Has buscado en los archivos de nuestra lista de correo? http://archives.postgresql.org/pgsql-es-ayuda
Re: [pgsql-es-ayuda] problema: FATAL: role postgres is not permitted to log in
Muchas gracias.. funciono perfectamente.. solo agrego que una vez entrado a modo standalone escribi lo siguiente: alter role postgres login; control+d Saludos.. -- TIP 2: puedes desuscribirte de todas las listas simultáneamente (envía unregister TuDirecciónDeCorreo a majord...@postgresql.org)
Re: [pgsql-es-ayuda] Problema con Funcion Llamada por Trigger
Si es posible intenta con AFTER en vez de BEFORE en la creacion del trigger 2009/11/25 Jorge Jacques jo...@eskalonnetwork.com: Hola, beun día Tengo un problema con una función, que al ejecutarse por un Trigger devuelve NULL y no encuentro la razón. --- CREATE OR REPLACE FUNCTION public.actua_desref () RETURNS trigger AS $BODY$ DECLARE empeno record; fechahoy date; fechaven date; diasm int; inmo float; BEGIN IF TG_OP='INSERT' THEN IF (NEW.tipo = 1 AND NEW.concepto = 1) OR (NEW.tipo = 1 AND NEW.concepto = 2) THEN SELECT INTO empeno fecha_venta, prestamo FROM empenos WHERE id=NEW.id; fechahoy = current_date; fechaven = TIMESTAMP WITH TIME ZONE 'epoch' + empeno.fecha_venta * INTERVAL '1 second'; diasm = fechahoy - fechaven; inmo = ((0.5 * empeno.prestamo::float)/100) * diasm; NEW.cantidad = NEW.cantidad::float + inmo; return NEW; END IF; END IF; END $BODY$ LANGUAGE 'plpgsql' --- CREATE TRIGGER calc_inmo BEFORE INSERT ON caja FOR EACH ROW EXECUTE PROCEDURE actua_desref() --- Al hacer un Insert Obtengo un: SQL Error: ERROR: null value in column “cantidad” violates not-null constraint. Esto me idica que el registro que regresa la funcion trae el campo cantidad a NULL, y no deberia ser así. Adicional a esto tengo una funcion que hice para probar que todo funcione correctamente (independientemente de esta) y al llamarla si me ejecuta correctamente: --- CREATE OR REPLACE FUNCTION public.pruebas () RETURNS float8 AS $BODY$ DECLARE empeno record; fechahoy date; fechaven date; diasm int; inmo float; BEGIN SELECT INTO empeno fecha_venta, prestamo FROM empenos WHERE id=1618; fechahoy = current_date; fechaven = TIMESTAMP WITH TIME ZONE 'epoch' + empeno.fecha_venta * INTERVAL '1 second'; diasm = fechahoy - fechaven; inmo = ((0.5 * empeno.prestamo::float)/100) * diasm; return inmo; END $BODY$ LANGUAGE 'plpgsql' --- Alguna sugerencia? Gracias!!! Saluos! -- TIP 8: explain analyze es tu amigo
[pgsql-es-ayuda] pg_ctl status ERROR
Hola.. tengo un servidor en Freebsd 7.1 con postgres 8.3 y esta funcionando bien, el dia de hoy quise hacer una actualización a la configuración y no pude reinciar el servidor, ni recargar el archivo ni nada.. como si este no existiera.. de hecho en algunas ocaciones me mando error de que no exite el archivo postmaster.pid en el directorio de configuracion... checo y si esta el archivo, lo mas raro es que el sistema sigue funcionando me conecto con el comando psql y no hay problema y por ultimo para checar le doy : pg_ctl status y me dice que no hay ningun servidor corriendo... Saludos y espero sus aportaciones.. gracias de antemano Motum Hesa... -- TIP 5: ¿Has leído nuestro extenso FAQ? http://www.postgresql.org/docs/faqs.FAQ.html
[pgsql-es-ayuda] Recomendacion para replicacion en WINDOWS
Ok... muchas gracias por las respuestas, mas que nada fue una consulta de un colega y pues como no pude responderle me dirigi a ustedes: ¿Que tipo de sistema tienes que necesita esta funcionalidad? -- Rafael Martinez, r.m.guerr...@usit.uio.no Center for Information Technology Services University of Oslo, Norway el tipo de sistema es mas o menos asi: 1.- Una base de datos en un servidor posgres con informacion de la produccion de una planta que es accesada diariamente y a cada rato, por lo que investigue pues nada que postgres no pueda soportar 2.- La empresa en la que trabaja mi colega es una transnacional que tiene 20 plantas en todo el mundo, por lo que segun se la idea es interconectar todos los servidores locales en uno para que que todos tengan la informacion de la produccion lo mas actualizada posible. de hecho la idea es hacer replicacion entre ellas. Como ya les habia comentado intente sugerir desarrollar un programa que guardara los datos y que se comunicara con el server para insertarlos posteriormente, tambien sugeri Oracle pero no me contesto, debido a que estoy seguro que el no sabe Oracle y no queria meterse en problemas.. jejeje Que yo sepa no existe ninguna solucion multi-maestro actualmente que este lista para funcionar con PostgreSQL en produccion. Hace un tiempo existia un projecto llamado 'pgclusters' que implementaba esto, pero por desgracia habia que parchear mucho el nucleo de postgresql y solamente lo mantenia una persona. Si necesitas funcionalidad de multimaestro, te queda RAC de Oracle o ASE de Sybase. Creo que DB2 tambien tiene esta posibilidad disponible. Pero la complejidad de administrar un sistema de este tipo a veces no merece la pena y en muchos casos es hasta innecesario. Bueno, gracias a sus respuestas puedo decirle mas claramete que tiene muchos problemas y tendras mas si intenta implementar replicacion multimaestro en windows... Lo que si voy a tener que plantearle es una forma convincente de tomar otras medidas para solucionar su problema, si tienen alguna sugerecia soy todo oidos... Saludos y nuevamente muchas gracias por sus respuestas.. Motum Hesa P.D. Gracias Alvaro por las aclaraciones... y las sugerencias.. :D .. Saludos... -- TIP 8: explain analyze es tu amigo
[pgsql-es-ayuda] Recomendacion para replicacion en WINDOWS
¿Que lenguaje de programación estas usando? Pues son 2 principalmente JAVA y C#, pero se me ocurre que podria realizar una aplicacion independiente para esto Se me ocurre que quizás puedas modificar un poco la aplicación (o el driver de conexión a la base de datos) para hacer commit en dos fases. Sds Mariano ok, la verdad no se a que te refieras con el commint en dos fases pero en un rato libre le busco a ver que encuentro, si tienes algo de informacion te lo agradeceria... Saludos Motum Hesa -- TIP 8: explain analyze es tu amigo
Re: [pgsql-es-ayuda] Recomendacion para replicacion en WINDOWS
En este caso lo que puedes hacer es replicar la informacion de cada planta a cada una de las otras plantas (pero las otras plantas no pueden modificar de una planta que no sea si misma). Eso no tiene nada de especial, para Slony es un sistema maestro-esclavo comun y corriente. -- Alvaro Herrera Valdivia, Chile ICBM: S 39º 48' 55.3, W 73º 15' 24.7 La espina, desde que nace, ya pincha (Proverbio africano) Ok.. gracias Alvaro, de hecho ya lo habia pensando aunque no tenia bien definido como plantearlo y de hecho me agrada mas esta opcion que la del COMMINT en dos faces principalmente por lo que comenta Manuel Diego, pero las dos opciones pueden ser validas. De verdad gracias por sus comentarios, su experiencia me ayuda bastante... Saludos y espero algun dia poder aportar en vez de solo preguntar (seguire leyendo manuales por lo mientras ;) )... P.D. Si alguien tiene otra idea con gusto leere todas los comentarios. -- TIP 7: no olvides aumentar la configuración del free space map
Re: [pgsql-es-ayuda] Cambiando parametros del kernel
Hola Rafael: Hola ¿Cual es el tamaño estimado de la base de datos? La base de datos ahorita es de aproximamente 100MB... pero estamos hablando de que se pretenden agregar unos 100kb por minuto... dependiendo de la informacion generada externamente... asi que estariamos hablado en un mes de una base de datos de mas de 4GB Estas hablando de 100 usuarios conectados, pero ¿son conexiones abiertas sin usar la base de datos todo el tiempo, o conexiones abiertas usando la base de datos concurrentemente? Existen varios tipos de clientes: 1.-Los que van a estar agregando la informacion que viene de diferentes sockets.. por lo que seria una conexion que se abre y cierra continuamente... por cada hilo.. ya agrege un pool a mi programa para evitar estar abriendo tantas conexiones 2.- Un programa que debe consultar la base de datos continuamente.. para saber si se han agregado datos binarios a la BD1, para traducirlo y expandirlos en campos coherentes de la BD2.. a este programa tambien le agrege un pool de conexiones aunque no parece necesario ya que casi siempre va a tener 2 conexiones abiertas uno a BD1 y otra BD2... 3.- Un servidor web con glassfish... que va a ser el k va a recibir la mayor parte de los clientes.. como el sistema web esta diseñado para dar seguimiento a una flotilla de autos.. este debe estarse consultando todo el tiempo... ( claro los usuarios deben actualizar la pag) si todo sale bien.. pensamos distribuir el sistema a un buen numero de clientes por lo que debe asegurar que aunque sea un sistema web.. es posible que tenga muchos clientes haciendo consultas cada rato... en general este es el por que de 100 usuarios... Unos datos orientativos para empezar, en un servidor dedicado para la base de datos, y que por supuesto deberian de ajustarse dependiendo del tipo de base de datos que tengas y como se utiliza, son: * shared_buffers = 25-30% RAM * work_men = [1]512k, [2]2MB, [3]128MB (nunca mas de RAM/num.conexiones) * maintenance_work_mem = 1/16 RAM * checkpoints_segments = [1]8, [2][3]16-64 * wal_buffers = [1]1MB, [2][3]8MB * effective_cache_size = 2/3 RAM * random_page_cost = 2.0 [1] Aplicacion Web [2] Tipica app. OLTP [3] Tipica app. datawarehouse Gracias por los datos.. me dan una idea de como implementar en mi server.. pero como comentaba al principio... mi sistema operativo FREEBSD no me deja poner mas de 40 conexiones... y pues gracias a Espartano ( nuevamente ) ya cheque la pag del manual... espero que no me provoque ningun problema.. jejeje.. ultimamente me la he pasado componiendo cosas que descompuse por componer otras.. ;)... bueno en fin gracias por los tips.. y si con la informacion que les pongo me pueden dar mas consejos se los agradecere... Saludos Motum Hesa -- TIP 1: para suscribirte y desuscribirte, visita http://archives.postgresql.org/pgsql-es-ayuda
[pgsql-es-ayuda] Cambiando parametros del kernel
Hola, tengo un servidor con FreeBSD 7.1 ( en un XEON Core 2 Duo, 2GB en RAM y 150GB en DD) la configuración de postgresql.conf por default coloco los siguientes valores: max_connections = 40 shared_buffers = 24MB #work_mem = 1MB como veran la ultima linea esta comentada, la pregunta es.. tengo un varios programas en JAVA que usan un par de bases de datos de en total unas 100 tablas, esta previsto que se conecte unos 100 clientes a la vez, claramente puedo ver que no va a ser soportado, ni aun usando pool de conexion ya que varias conexiones deben permanecer abiertas y en pruebas ya he saturado el numero de conexiones ( no se si es el pgadmin que hay veces que se me cierra en windows y deja las conexiones abiertas) y pues me gustaria que me recomendaran valores para estas opciones, cabe mencionar que ya quise cambiarlos y me mando error.. leyendo en los manuales encontre el siguiente punto: http://www.postgresql.org/docs/8.4/interactive/kernel-resources.html El problema es que yo tengo postgresql 8.2.9 y no se si aplique lo que mencionan de las variables y semaforos del kernel para esta version... si es asi que valores recomiendan... Saludos y gracias de antemano por su ayuda Motum Hesa -- TIP 7: no olvides aumentar la configuración del free space map
[pgsql-es-ayuda] PL/JAVA en FreeBSD
-- Mensaje reenviado -- De: motum hesa mot...@gmail.com Fecha: 16 de julio de 2009 20:15 Asunto: Re: [pgsql-es-ayuda] PL/JAVA en FreeBSD Para: Emanuel Calvo Franco postgres@gmail.com Bueno... ya logre solucionar mis problemas con pl/java y siguiendo los paso que realice y con ayuda de un amigo, ahora tengo un link que explica claramente lo que se debe hacer: http://www.adempiere.com/index.php/How_To_Run_ADempiere_on_FreeBSD Asi que espero que les sirva de algo... Saludos P.D. Gracias Espartano...:p -- TIP 2: puedes desuscribirte de todas las listas simultáneamente (envía unregister TuDirecciónDeCorreo a majord...@postgresql.org)
[pgsql-es-ayuda] PL/JAVA en FreeBSD
Hola.. despues de un rato de estar intentando he decidido pedir su ayuda, resulta que tengo que instalar pl/java version 1.4 en freebsd 7.1 pero a la hora de ejecutar el script de install me dice que falta la libreria libc.so.6 por lo que lei deberia de usar la libc.so.7 pero pues ya intente de todo.. desde instalar compat6x hasta hacer links simbolicos.. pero no logro instalar pl/java... tomando en cuenta que FreeBSD no es propiamente un linux entonces descargue el codigo fuente para compilarlo pero me manda un error que por el momento estoy tratando de solucionar, mi pregunta es, alguien a instalado PL/JAVA en FreeBSD 7.1? si es asi, alguna sugerencia.. Saludos... Motum Hesa -- TIP 8: explain analyze es tu amigo
Re: [pgsql-es-ayuda] PL/JAVA en FreeBSD
Hola de nuevo: Agregando información a mi correo anterior, tengo Postgres 8.2.9 instalado, FreeBSD 7.1, diablo-jdk 1.6 y Glib 2.16. creo que eso es todo lo necesario para que tengan mas claro el problema, si necesitan mas infor con gusto la agrego.. Saludos Motum Hesa -- TIP 6: ¿Has buscado en los archivos de nuestra lista de correo? http://archives.postgresql.org/pgsql-es-ayuda
[pgsql-es-ayuda] Que es mejor NULL o CERO
Tengo una base de datos, que se tiene previsto crecera considerablemente, para tratar de minimizar el costo en disco duro me gustaria saber si puedo obetener algun provecho al guardar varios de los datos en null en los campos numerios en vez de cero. por lo cual la pregunta seria, es mas conveniente usar null en vez de cero para optimizar la base de datos? Saludos
Re: [pgsql-es-ayuda] Que es mejor NULL o CERO
Muchas gracias a los comentarios de todos, son muy interesantes, ya lei los links que me mandaron y tomare en cuenta las sugerencias, sin embargo me asalta otra duda sobre lo mismo,... si declaro un int de 4 bytes y guardo un 0 es seguro que se reservan los 4 bytes.. pero si guardo un null tambien se reservan los 4 bytes?, saludos y gracias El 25 de junio de 2009 15:10, Alvaro Herrera alvhe...@alvh.no-ip.orgescribió: motum hesa escribió: Tengo una base de datos, que se tiene previsto crecera considerablemente, para tratar de minimizar el costo en disco duro me gustaria saber si [...] A todo esto, es bien posible que puedas obtener mejor uso del espacio en disco si estudias con cuidado el orden de las columnas para reducir el gasto por alineamiento, de haberlo. -- Alvaro Herrera Developer, http://www.PostgreSQL.org/ El sudor es la mejor cura para un pensamiento enfermo (Bardia)
