Re: [pgsql-es-ayuda] LIKE a campo integer
Herman Estaban escribió: > Tengo una tabla PRD_REG con 02 campos: > > ID_TIP_REG INTEGER > NOM_TIP_REG VARCHAR(25) > > Esta tabla tiene 14 registros y esta registrado asi: > > ID_TIP_REG | NOM_TIP_REG > 1 | DETALLADO > 2 | MARCADO > 3 | PROGRAMADO > 4 | CON DISEÑO > 5 | SIN DISEÑO > . > . > . > 99 | SIN REGISTRAR > > He creado un funcion, que tiene un parametro (param) de tipo INTEGER, en > esta funcion la que esta tabla PRD_REG se cruza con JOIN con otra tabla y > en el WHERE quiero usar un LIKE ya que el usuario puede elegir cualquiera > de los codigos de la tabla PRD_REG, como tambien todos por eso necesito el > LIKE. > > Por eso utilizo esto: > WHERE CAST(ID_TIP_REG AS CHAR) LIKE param; Suena a mal diseño de la función. consulta := 'select bla bla from prd_reg ' if param IS NOT NULL then consulta := consulta || 'where id_tip_reg = ' || param end if; execute consulta; Así, si le pasas un NULL a param significa "todos", pero si es un valor específico entonces trae los registros de ese código. Alternativamente, si quieres varios códigos, podrías usar = ANY, select .. from prd_reg where id_tip_reg = any (1, 4, 6) -- Álvaro Herrerahttp://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services - Enviado a la lista de correo pgsql-es-ayuda (pgsql-es-ayuda@postgresql.org) Para cambiar tu suscripción: http://www.postgresql.org/mailpref/pgsql-es-ayuda
Re: [pgsql-es-ayuda] LIKE a campo integer
Buenas. Lo mas simple para esto es usar un OR -- SELECT * FROM PRD_REG WJERE (ID_TIP_REG = param OR param = 0) Saludos. El 22 de junio de 2016, 9:31, Alvaro Herrera escribió: > Herman Estaban escribió: > > > Tengo una tabla PRD_REG con 02 campos: > > > > ID_TIP_REG INTEGER > > NOM_TIP_REG VARCHAR(25) > > > > Esta tabla tiene 14 registros y esta registrado asi: > > > > ID_TIP_REG | NOM_TIP_REG > > 1 | DETALLADO > > 2 | MARCADO > > 3 | PROGRAMADO > > 4 | CON DISEÑO > > 5 | SIN DISEÑO > > . > > . > > . > > 99 | SIN REGISTRAR > > > > He creado un funcion, que tiene un parametro (param) de tipo INTEGER, en > > esta funcion la que esta tabla PRD_REG se cruza con JOIN con otra tabla y > > en el WHERE quiero usar un LIKE ya que el usuario puede elegir cualquiera > > de los codigos de la tabla PRD_REG, como tambien todos por eso necesito > el > > LIKE. > > > > Por eso utilizo esto: > > WHERE CAST(ID_TIP_REG AS CHAR) LIKE param; > > Suena a mal diseño de la función. > > consulta := 'select bla bla from prd_reg ' > if param IS NOT NULL then >consulta := consulta || 'where id_tip_reg = ' || param > end if; > execute consulta; > > Así, si le pasas un NULL a param significa "todos", pero si es un valor > específico entonces trae los registros de ese código. > > Alternativamente, si quieres varios códigos, podrías usar = ANY, > select .. from prd_reg where id_tip_reg = any (1, 4, 6) > > -- > Álvaro Herrerahttp://www.2ndQuadrant.com/ > PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services > > - > Enviado a la lista de correo pgsql-es-ayuda (pgsql-es-ayuda@postgresql.org > ) > Para cambiar tu suscripción: > http://www.postgresql.org/mailpref/pgsql-es-ayuda > -- *Ing. Eduardo Reyes* Analista Programador. (809) 607-1961 ere...@h-rivera.com
Re: [pgsql-es-ayuda] LIKE a campo integer
eduardo reyes escribió: > Buenas. > Lo mas simple para esto es usar un OR > -- > SELECT * >FROM PRD_REG > WJERE (ID_TIP_REG = param OR param = 0) Ya ven lo que pasa cuando uno responde antes de desayunar -- tu solución es mucho más simple. Pero yo usaría NULL en vez de 0: SELECT * FROM PRD_REG WHERE (ID_TIP_REG = param OR param IS NULL) -- Álvaro Herrerahttp://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services - Enviado a la lista de correo pgsql-es-ayuda (pgsql-es-ayuda@postgresql.org) Para cambiar tu suscripción: http://www.postgresql.org/mailpref/pgsql-es-ayuda
[pgsql-es-ayuda] problemas pg_dump
Hola a todos he revisado el foro de consultas y aun no enrontrado aún con algo parecido a mi pregunta. Tengo un cron el el server de la base de datos que realiza el respaldo todos los dias a una hora fija. se realiza un vacuum full analyze y posterior Pg_dump esto ha funcionado desde hace bastante tiempo sin problemas, pero las ultimas semanas, en reiteradas ocasiones hemos encontrado el proceso 'pegado'. Entiendo que los logs, son importante en estos casos, es por ello me orienten la forma de detectar o configurar para que los log me puedan entregar la información puede estar ocurriendo. Y cual es la mejor manera de volver a que la bd funcione correctamente , pues estoy en duda en solo reiniciar el servicio, terminar el proceso que esta causando conflicto o ningunas delas anteriores. Muchas gracias y saludos 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] problemas pg_dump
Hola Silvana: 1.- Define 'pegado' 2.- Después del vacuum full analyze, hacías un Reindex 3.- Has trabajado con PgBadger para análisis de logs?? Saludos Cordiales Mario Soto -Mensaje original- De: pgsql-es-ayuda-ow...@postgresql.org [mailto:pgsql-es-ayuda-ow...@postgresql.org] En nombre de Silvana Flores Enviado el: miércoles, 22 de junio de 2016 11:04 Para: FORO POSTGRES Asunto: [pgsql-es-ayuda] problemas pg_dump Hola a todos he revisado el foro de consultas y aun no enrontrado aún con algo parecido a mi pregunta. Tengo un cron el el server de la base de datos que realiza el respaldo todos los dias a una hora fija. se realiza un vacuum full analyze y posterior Pg_dump esto ha funcionado desde hace bastante tiempo sin problemas, pero las ultimas semanas, en reiteradas ocasiones hemos encontrado el proceso 'pegado'. Entiendo que los logs, son importante en estos casos, es por ello me orienten la forma de detectar o configurar para que los log me puedan entregar la información puede estar ocurriendo. Y cual es la mejor manera de volver a que la bd funcione correctamente , pues estoy en duda en solo reiniciar el servicio, terminar el proceso que esta causando conflicto o ningunas delas anteriores. Muchas gracias y saludos 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 - 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: [MASSMAIL][pgsql-es-ayuda] problemas pg_dump
> Hola a todos he revisado el foro de consultas y aun no enrontrado aún > con algo parecido a mi pregunta. > > Tengo un cron el el server de la base de datos que realiza el respaldo > todos los dias a una hora fija. > se realiza un vacuum full analyze y posterior Pg_dump > > esto ha funcionado desde hace bastante tiempo sin problemas, pero las > ultimas semanas, en reiteradas ocasiones hemos encontrado el proceso > 'pegado'. > Entiendo que los logs, son importante en estos casos, es por ello me > orienten la forma de detectar o configurar para que los log me puedan > entregar la información puede estar ocurriendo. > Y cual es la mejor manera de volver a que la bd funcione correctamente > , pues estoy en duda en solo reiniciar el servicio, terminar el proceso > que esta causando conflicto o ningunas delas anteriores. > > Muchas gracias y saludos a todos..! > Uhmm, doy mi criterio si usas autovacuum, a mi entender no necesitas hacer el vacuum full, tampoco veo mucha importancia en la operación de analyze en ese caso. Deber chequear el crecimiento de tu data, puede ser que un dump continuo ya no se la mejor idea. -- Saludos, Gilberto Castillo ETECSA, La Habana, Cuba - 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 pg_dump
El 22-06-2016 a las 11:14, Mario Soto Cordones escribió: Hola Silvana: 1.- Define 'pegado' Al realizar un ps -aux en debian aparece vacuum sin finalizar o bloqueado (colgado o pegado segun yo) por ende no realiza el dump y todos los otros procesos y conexiones a la bd estan en espera. 2.- Después del vacuum full analyze, hacías un Reindex no. 3.- Has trabajado con PgBadger para análisis de logs?? no Saludos Cordiales Mario Soto -Mensaje original- De: pgsql-es-ayuda-ow...@postgresql.org [mailto:pgsql-es-ayuda-ow...@postgresql.org] En nombre de Silvana Flores Enviado el: miércoles, 22 de junio de 2016 11:04 Para: FORO POSTGRES Asunto: [pgsql-es-ayuda] problemas pg_dump Hola a todos he revisado el foro de consultas y aun no enrontrado aún con algo parecido a mi pregunta. Tengo un cron el el server de la base de datos que realiza el respaldo todos los dias a una hora fija. se realiza un vacuum full analyze y posterior Pg_dump esto ha funcionado desde hace bastante tiempo sin problemas, pero las ultimas semanas, en reiteradas ocasiones hemos encontrado el proceso 'pegado'. Entiendo que los logs, son importante en estos casos, es por ello me orienten la forma de detectar o configurar para que los log me puedan entregar la información puede estar ocurriendo. Y cual es la mejor manera de volver a que la bd funcione correctamente , pues estoy en duda en solo reiniciar el servicio, terminar el proceso que esta causando conflicto o ningunas delas anteriores. Muchas gracias y saludos 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 -- Silvana Flores Vallejos Departamento de Computación e Informática Unidad de Desarrollo de Sistemas Centro de Formación Técnica Lota - Arauco Carlos Cousiño 184 Lota Alto Fono: 412262516 - 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] LIKE a campo integer
Gracias por sus aportes. Saludos. El mié., 22 jun. 2016 a las 9:48, Alvaro Herrera () escribió: > eduardo reyes escribió: > > Buenas. > > Lo mas simple para esto es usar un OR > > -- > > SELECT * > >FROM PRD_REG > > WJERE (ID_TIP_REG = param OR param = 0) > > Ya ven lo que pasa cuando uno responde antes de desayunar -- tu > solución es mucho más simple. Pero yo usaría NULL en vez de 0: > > SELECT * > FROM PRD_REG >WHERE (ID_TIP_REG = param OR param IS NULL) > > -- > Álvaro Herrerahttp://www.2ndQuadrant.com/ > PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services > > - > Enviado a la lista de correo pgsql-es-ayuda (pgsql-es-ayuda@postgresql.org > ) > Para cambiar tu suscripción: > http://www.postgresql.org/mailpref/pgsql-es-ayuda >
RE: [pgsql-es-ayuda] problemas pg_dump
Cual es el nivel de verbosidad para los log en tu postgresql.conf? Cuando el proceso está "pegado", as analizado el resultado de ésta query? SELECT now() - pg_stat_activity.query_start AS runtime, pg_stat_activity.pid, pg_stat_activity.usename, pg_stat_activity.waiting, pg_stat_activity.query, pg_stat_activity.application_name AS appname, pg_stat_activity.state FROM pg_stat_activity ORDER BY now() - pg_stat_activity.query_start DESC; Saludos -Mensaje original- De: Silvana Flores [mailto:sflo...@cftlotarauco.cl] Enviado el: miércoles, 22 de junio de 2016 11:21 Para: Mario Soto Cordones ; 'FORO POSTGRES' Asunto: Re: [pgsql-es-ayuda] problemas pg_dump El 22-06-2016 a las 11:14, Mario Soto Cordones escribió: > Hola Silvana: > > 1.- Define 'pegado' Al realizar un ps -aux en debian aparece vacuum sin finalizar o bloqueado (colgado o pegado segun yo) por ende no realiza el dump y todos los otros procesos y conexiones a la bd estan en espera. > 2.- Después del vacuum full analyze, hacías un Reindex no. > 3.- Has trabajado con PgBadger para análisis de logs?? no > > Saludos Cordiales > > Mario Soto > > -Mensaje original- > De: pgsql-es-ayuda-ow...@postgresql.org > [mailto:pgsql-es-ayuda-ow...@postgresql.org] En nombre de Silvana > Flores Enviado el: miércoles, 22 de junio de 2016 11:04 > Para: FORO POSTGRES > Asunto: [pgsql-es-ayuda] problemas pg_dump > > Hola a todos he revisado el foro de consultas y aun no enrontrado aún > con algo parecido a mi pregunta. > > Tengo un cron el el server de la base de datos que realiza el respaldo > todos los dias a una hora fija. > se realiza un vacuum full analyze y posterior Pg_dump > > esto ha funcionado desde hace bastante tiempo sin problemas, pero las > ultimas semanas, en reiteradas ocasiones hemos encontrado el proceso > 'pegado'. > Entiendo que los logs, son importante en estos casos, es por ello me > orienten la forma de detectar o configurar para que los log me puedan > entregar la información puede estar ocurriendo. > Y cual es la mejor manera de volver a que la bd funcione > correctamente , pues estoy en duda en solo reiniciar el servicio, > terminar el proceso que esta causando conflicto o ningunas delas anteriores. > > Muchas gracias y saludos 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 > -- Silvana Flores Vallejos Departamento de Computación e Informática Unidad de Desarrollo de Sistemas Centro de Formación Técnica Lota - Arauco Carlos Cousiño 184 Lota Alto Fono: 412262516 - 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 pg_dump
Hola Silvana, ejecutar un vaccum FULL todos los días no se si será una idea buena :-\ , una vez manejé un server sin el autovaccum pero ejecutaba el vaccum todas la noches a las tablas que lo necesitaban y un full una vez al mes solamente, pues la documentación te dice que el FULL tienes sus cosas : FULL: Selects"full"vacuum, which can reclaim more space, but takes much longer and exclusively locks the table. This method also requires extra disk space, since it writes a new copy of the table and doesn't release the old copy until the operation is complete. Usually this should only be used when a significant amount of space needs to be reclaimed from within the table. Imagino que conozcas la diferencia entre el vacuum y el vaccum full. Pero si realmente lo necesitas (FULL), mira a ver que está retornando cuando se está el ejecutando la actividad el : pg_stat_activity Saludos __ On 22/06/16 11:03, Silvana Flores wrote: Hola a todos he revisado el foro de consultas y aun no enrontrado aún con algo parecido a mi pregunta. Tengo un cron el el server de la base de datos que realiza el respaldo todos los dias a una hora fija. se realiza un vacuum full analyze y posterior Pg_dump esto ha funcionado desde hace bastante tiempo sin problemas, pero las ultimas semanas, en reiteradas ocasiones hemos encontrado el proceso 'pegado'. Entiendo que los logs, son importante en estos casos, es por ello me orienten la forma de detectar o configurar para que los log me puedan entregar la información puede estar ocurriendo. Y cual es la mejor manera de volver a que la bd funcione correctamente , pues estoy en duda en solo reiniciar el servicio, terminar el proceso que esta causando conflicto o ningunas delas anteriores. Muchas gracias y saludos 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] problemas pg_dump
Gracias!! El 22-06-2016 a las 11:33, Mario Soto Cordones escribió: Cual es el nivel de verbosidad para los log en tu postgresql.conf? Creo que a esto debo ponermas atención, para encontrar lo optimo.! Cuando el proceso está "pegado", as analizado el resultado de ésta query? SELECT now() - pg_stat_activity.query_start AS runtime, pg_stat_activity.pid, pg_stat_activity.usename, pg_stat_activity.waiting, pg_stat_activity.query, pg_stat_activity.application_name AS appname, pg_stat_activity.state FROM pg_stat_activity ORDER BY now() - pg_stat_activity.query_start DESC; Saludos -Mensaje original- De: Silvana Flores [mailto:sflo...@cftlotarauco.cl] Enviado el: miércoles, 22 de junio de 2016 11:21 Para: Mario Soto Cordones ; 'FORO POSTGRES' Asunto: Re: [pgsql-es-ayuda] problemas pg_dump El 22-06-2016 a las 11:14, Mario Soto Cordones escribió: Hola Silvana: 1.- Define 'pegado' Al realizar un ps -aux en debian aparece vacuum sin finalizar o bloqueado (colgado o pegado segun yo) por ende no realiza el dump y todos los otros procesos y conexiones a la bd estan en espera. 2.- Después del vacuum full analyze, hacías un Reindex no. 3.- Has trabajado con PgBadger para análisis de logs?? no Saludos Cordiales Mario Soto -Mensaje original- De: pgsql-es-ayuda-ow...@postgresql.org [mailto:pgsql-es-ayuda-ow...@postgresql.org] En nombre de Silvana Flores Enviado el: miércoles, 22 de junio de 2016 11:04 Para: FORO POSTGRES Asunto: [pgsql-es-ayuda] problemas pg_dump Hola a todos he revisado el foro de consultas y aun no enrontrado aún con algo parecido a mi pregunta. Tengo un cron el el server de la base de datos que realiza el respaldo todos los dias a una hora fija. se realiza un vacuum full analyze y posterior Pg_dump esto ha funcionado desde hace bastante tiempo sin problemas, pero las ultimas semanas, en reiteradas ocasiones hemos encontrado el proceso 'pegado'. Entiendo que los logs, son importante en estos casos, es por ello me orienten la forma de detectar o configurar para que los log me puedan entregar la información puede estar ocurriendo. Y cual es la mejor manera de volver a que la bd funcione correctamente , pues estoy en duda en solo reiniciar el servicio, terminar el proceso que esta causando conflicto o ningunas delas anteriores. Muchas gracias y saludos 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 - 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 pg_dump
Muchisimas gracias, estudiare cada una de sus recomendaciones..! El 22-06-2016 a las 11:46, Anthony Sotolongo escribió: Hola Silvana, ejecutar un vaccum FULL todos los días no se si será una idea buena :-\ , una vez manejé un server sin el autovaccum pero ejecutaba el vaccum todas la noches a las tablas que lo necesitaban y un full una vez al mes solamente, pues la documentación te dice que el FULL tienes sus cosas : FULL: Selects"full"vacuum, which can reclaim more space, but takes much longer and exclusively locks the table. This method also requires extra disk space, since it writes a new copy of the table and doesn't release the old copy until the operation is complete. Usually this should only be used when a significant amount of space needs to be reclaimed from within the table. Imagino que conozcas la diferencia entre el vacuum y el vaccum full. Pero si realmente lo necesitas (FULL), mira a ver que está retornando cuando se está el ejecutando la actividad el : pg_stat_activity Saludos __ On 22/06/16 11:03, Silvana Flores wrote: Hola a todos he revisado el foro de consultas y aun no enrontrado aún con algo parecido a mi pregunta. Tengo un cron el el server de la base de datos que realiza el respaldo todos los dias a una hora fija. se realiza un vacuum full analyze y posterior Pg_dump esto ha funcionado desde hace bastante tiempo sin problemas, pero las ultimas semanas, en reiteradas ocasiones hemos encontrado el proceso 'pegado'. Entiendo que los logs, son importante en estos casos, es por ello me orienten la forma de detectar o configurar para que los log me puedan entregar la información puede estar ocurriendo. Y cual es la mejor manera de volver a que la bd funcione correctamente , pues estoy en duda en solo reiniciar el servicio, terminar el proceso que esta causando conflicto o ningunas delas anteriores. Muchas gracias y saludos 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
[pgsql-es-ayuda] Pregunta sobre indices
Hola, tengo una consulta sobre Indices. Por lo que he leído los Indices me sirven para que la búsqueda sea mas rápida. Tengo una tabla (por dar un ejemplo) que tiene un PK y 2 FK CREATE TABLE cliente ( id_cliente INTEGER NOT NULL (PK) id_sucursal INTEGER NOT NULL (FK) id_documento INTEGER NOT NULL (FK) Mi pregunta es cuando se crea en una tabla los campos Primary Key y Foreign Key estos por defecto ya son Indices? o debo de crearlos independientemente? De ser la respuesta no entonces debo crear 2 indices para id_sucursal y id_documento? Si no es molestia podrían por favor compartir su experiencia para aclarar mi duda o si tienen algún enlace sobre el tema. Gracias de antemano.
