Re: [pgsql-es-ayuda] Consulta sobre rangos no contiguos

[Hellmuth Vargas]

Hola Lista

Aunque no es puramente operaciones con rangos plateo esta solución:


select tsrange(min(dato),max(dato))
from (
select *,sum(rangos) over(order by  dato asc) as grupo
from (
select *,case when dato -lag(dato) over(order by  dato asc)<>'30
minutes'::interval then 1 else 0 end as rangos
from (
select * from generate_series(lower('[2015-11-27 09:30:00,2015-11-27
18:00:00)'::tsrange),upper('[2015-11-27 09:30:00,2015-11-27
18:00:00)'::tsrange),'30 minutes'::interval) as a(dato)
except
select * from generate_series(lower('[2015-11-27 10:30:00,2015-11-27
11:00:00)'::tsrange),upper('[2015-11-27 10:30:00,2015-11-27
11:00:00)'::tsrange),'30 minutes'::interval) as a(dato)
) as i order by dato asc
) as i
) as j group by  grupo



test#;
tsrange
---
 ["2015-11-27 11:30:00","2015-11-27 18:00:00")
 ["2015-11-27 09:30:00","2015-11-27 10:00:00")
(2 rows)





El 23 de junio de 2017, 08:12, Stephen Amell
escribió:

> Buenos días comunidad postgresista!
>
> Hoy les escribo para consultarles a ver si me dan una idea sobre como
> encarar un problema de rangos timestamp
>
> Dado un rango de atención: '["2015-11-27 09:30:00","2015-11-27
> 18:00:00")'::tsrange
> Dado un rango de la duración de la atención: '["2015-11-27
> 10:30:00","2015-11-27 11:00:00")'::tsrange
>
> Necesito obtener el rango de atención libre, que serian dos rangos
> cortados por el medio.
>
> Lo primero que probé es  ver si funcionaba con un:
>
> select '["2015-11-27 09:30:00","2015-11-27 18:00:00")'::tsrange -
> '["2015-11-27 10:30:00","2015-11-27 11:00:00")'::tsrange
>
> ERROR: el resultado de la diferencia de rangos no sería contiguo
> SQL state: 22000
>
> Ahí empece a googlear y me encuentro que no es posible por limitaciones
> propias de postgres y quería saber si alguien me puede orientar con algún
> workaround o algo.
>
>
> Desde ya muchísimas gracias!
> Diego
>



-- 
Cordialmente,

Ing. Hellmuth I. Vargas S.
Esp. Telemática y Negocios por Internet
Oracle Database 10g Administrator Certified Associate
EnterpriseDB Certified PostgreSQL 9.3 Associate

Re: [pgsql-es-ayuda] Completar y compartir caracteristicas

[Hellmuth Vargas]

Hola Lista

En el sitio oficial de PostgreSQL existe un Feature Matrix:


https://www.postgresql.org/about/featurematrix/




El 16 de junio de 2017, 10:35, jvenegasperu .
escribió:

> Buen dia a todos hoy me llego a mi mail un boletin sobre
> comparacion entre Mysql y MariaDB
>
> que puede verse en esta dirección.
>
> https://dzone.com/storage/assets/5079507-mysql-vs-mariadb-whitepaper.pdf
>
> Asi que copie la tabla y le agregue lo poco que conozco de postgres aqui
> se las adjunto en ODT haber quien se anima a completar la tabla o agregar
> mas caracteristicas y reenviarla asi consolidamos una tablitay tenemos una
> idea de como vamos en relacion a estos otros motores
>
> saludos
>
> --
> José Mercedes Venegas Acevedo
> cel Mov RPC 964185205
>
> Member of the PHP Documentation Group (Spanish)
>
> -
> 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
>
>


-- 
Cordialmente,

Ing. Hellmuth I. Vargas S.

[pgsql-es-ayuda] preguntas sobre particionamiento nativo en PostgreSQL 10.

[Hellmuth Vargas]

Hola lista

dada la expectativa que esta generando la siguiente generación de nuestra
base de datos, estoy en la revisión  el documento "PostgreSQL 10 New
Features With Examples"

http://h50146.www5.hpe.com/products/software/oe/linux/mainstream/support/lcc/pdf/PostgreSQL_10_New_Features_en_20170522-1.pdf

tengo las siguientes preguntas sobre  el particionamiento nativo:


- migración desde el actual esquema de particiones (basado en herencia y
trigger) al nuevo esquema qeu implementa postgres 10

- cuando las condiciones sobre las claves de partición  constantes
compuestas hace la exclusión, ejemplo
where clave between '2017-01-01 00:00:00' and '2017-03-01  23:59:59'
aplica exclusión pero

  where clave between '2017-01-01 ' || '00:00:00' and '2017-03-01'  ||
'23:59:59' recorre todas las tablas que hacen parte de la partición

- sigue aplicando igual el parámetro constraint_exclution

- es posible colocar  particiones en diferentes tablespace


En general el documento cubre varios temas adicionales que bien vale la
pena analizar y evaluar su adopción dentro de nuestros sistemas
productivos, hasta ahora voy en este primer tema pero bien vale la pena que
sigamos "desmenuzando" los restantes.

-- 


Cordialmente,

Ing. Hellmuth I. Vargas S.

Re: [pgsql-es-ayuda] Vacuum

[Hellmuth Vargas]

Hola Diego

En primer lugar, esto sucede porque
- autovacuum inactivo
- no tenga programado  tareas de mantenimiento diarias con VACUUM  ó
*- Exista una transacción antigua, sin resolver, que no ha permitido la
ejecución del mantenimiento respectivo.*

 Ahora bien, porque la tabla presenta este tamaño  si tan solo tiene
algunos registros?, PostgreSQL, implementan un mecanismo llamado MVCC, lo
que  permite mantener varias "versiones" de un registro vigentes en el
espacio de una transacción en particular (para cumplir con los postulados
*ACID*-*A*tomicity, *C*onsistency, *I*solation and *D*urability:
Atomicidad, Consistencia, *Aislamiento* y Durabilidad en español): cada vez
que se actualiza una fila, en realidad la fila es marcada como obsoleta y
se inserta la nueva versión de la misma, por lo tanto, una tabla con muchas
actualizaciones podría tener un tamaño grande con respecto a la cantidad de
registros vigentes que en realidad contiene y ahí es donde entra el VACUUM
y específicamente el autovacuum, el cual monitorea las operaciones en las
tablas y realiza el mantenimiento sobre las mismas marcando las filas
obsoletas como disponibles para contener nuevos registros (siempre y cuando
no exista una  transacción   pendiente que la emplee) para su reutilización
 posterior o incluso (en el caso del VACUUM FULL) devuelve este espacio al
sistema operativo.

Como primer aproximación, verifique en la visita pg_stat_activity si
existen transacciones muy viejas aun sin resolver

El 5 de junio de 2017, 07:39, Gerardo Herzig escribió:

>
>
> - Mensaje original -
> > De: "Diego" 
> > Para: pgsql-es-ayuda@postgresql.org
> > Enviados: Lunes, 5 de Junio 2017 8:43:18
> > Asunto: [pgsql-es-ayuda] Vacuum
> >
> > Buenos días Postgresistas,
> >
> > Hoy les escribo para consultarles sobre una situación que me pasa con
> > una tabla.
> > Esta tabla tiene 31 registros y 3 campos, una pk y un indice, después de
> > un tiempo me doy cuenta que ocupa 595 MBs y 577 MBs de indices.
> >
> > Le hice un Vacuum manual a la tabla y arrojo lo siguiente sin reducir el
> > tamaño:
> >
> >
>
> Vacuum "a secas" no elimina espacio, mas bien lo reorganiza. Lo que vos
> queres se logra con VACUUM FULL, o recreandola (en la manera supongo que
> hiciste).
>
> HTH,
> Gerardo
>
> -
> 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
>



-- 
Cordialmente,

Ing. Hellmuth I. Vargas S.

[pgsql-es-ayuda] Re: [pgsql-es-ayuda] Qué modo sería mas eficiente configurar en PgBouncer, session mode o transaction mode?

[Hellmuth Vargas]

Hola

En el siguiente Blog hay un explicación sobre el tema

https://www.depesz.com/2012/12/02/what-is-the-point-of-bouncing/

El 20 de abril de 2017, 09:38, Lazaro Garcia escribió:

> Hola a todos. Me podrían dar sus recomendaciones sobre qué modo sería más
> eficiente utilizar en PgBouncer, sesion mode o transaction mode, con el
> propósito de obtener un mejor rendimiento de PostgreSQL.
>
>
>
> Me podrían compartir algún enlace donde pudiera leer al respecto.
>
>
>
> Saludos a todos.
>



-- 
Cordialmente,

Ing. Hellmuth I. Vargas S.
Esp. Telemática y Negocios por Internet
Oracle Database 10g Administrator Certified Associate
EnterpriseDB Certified PostgreSQL 9.3 Associate

Re: [pgsql-es-ayuda] Substring y expresiones regulares

[Hellmuth Vargas]

Hola Lista

Si no debe tener los puntos:

select 'abcfd 333 nnn DNI: 623663.99.99.9090 ldsklñdskñdksfmdlkffjdfd' as
dato,
replace(split_part(trim(split_part('abcfd 333 nnn DNI: 623663.99.99.9090
ldsklñdskñdksfmdlkffjdfd','DNI:',2)),' ',1),'.','') as resultado;

  dato|resultado
---+---
 abcfd 333 nnn DNI: 623663.99.99.9090 ldsklñdskñdksfmdlkffjdfd |
6236639090


Hola Francisco: no es apenas lógico que tendemos a resolver los
requerimientos con lo que mas dominamos y eso es lo enriquecedor de estas
listas de correo: que  podemos  obtener diferentes perspectivas para dar
solución a un requerimiento... 


El 23 de marzo de 2017, 13:24, Francisco Olarte<fola...@peoplecall.com>
escribió:

> Hellmuth:
>
> 2017-03-23 19:20 GMT+01:00 Hellmuth Vargas <hiv...@gmail.com>:
> > SELECT  'abcfd 333 nnn DNI: 623663.99.99.9090 ldsklñdskñdksfmdlkffjdfd'
> as
> > dato,
> > split_part(trim(split_part('abcfd 333 nnn DNI: 623663.99.99.9090
> > ldsklñdskñdksfmdlkffjdfd','DNI:',2)),' ',1) as resultado
>
> Nice. Reconozco que tras 30 años de perl tiendo a abusar de las regexp
> ( como valen pa tantas cosas nunca memorizo el resto de las funciones
> un pelin avanzadas que se pueden sustituir por ellas ), pero para la
> especificacion del problema es mas directo ( y con un trim o replace o
> algo asi seguro que se le pueden eliminar los puntos ).
>
> Francisco Olarte.
>




-- 
Cordialmente,

Ing. Hellmuth I. Vargas S.

Re: [pgsql-es-ayuda] Substring y expresiones regulares

[Hellmuth Vargas]

Hola Lista

SELECT  'abcfd 333 nnn DNI: 623663.99.99.9090 ldsklñdskñdksfmdlkffjdfd' as
dato,
split_part(trim(split_part('abcfd 333 nnn DNI: 623663.99.99.9090
ldsklñdskñdksfmdlkffjdfd','DNI:',2)),' ',1) as resultado

--

   dato|resultado
---+---
 abcfd 333 nnn DNI: 623663.99.99.9090 ldsklñdskñdksfmdlkffjdfd |
623663.99.99.9090






El 23 de marzo de 2017, 13:16, Francisco Olarte
escribió:

> Gerardo:
>
> 2017-03-23 17:57 GMT+01:00 Gerardo Herzig :
> >> Buenos dias
> >> Necesito extraer de un campo de texto los nros de DNI contenidos en
> >> él.
> >> Sé que los mismos se encuentran luego de la cadena 'DNI:'
> >>
> >> Con substring(texto from 'DNI:') ubico la cadena
> ...
>
> > Que tal una expresion regular para borrar todo lo que *no* sean numeros:
>
> Eso te vale si solo esta el dni, pero...
>
> >
> > select regexp_replace(texto, '[^0-9]', '','g') from tabla;
>
> > postgres=# select *, regexp_replace(dni, '[^0-9]', '','g') as
> solo_numeros from dnis;
> > dni | solo_numeros
> > +--
> >  DNI:12.382.712 | 12382712
> >  DNI:12382712   | 12382712
> >  DNI:123827..12 | 12382712
> > (3 rows)
> -- Que pasa si meto esto delante del select?
> copy dnis(dni) from stdin;
> Numero de telefono: 666
> DNI: desconocido, TEL: 12345678
> Tel: 6 DNI: 12345678 Direccion: Avda. Pensilvania 1600
> 44100 = 2*2*3*3*5*5*7*7, tricky uh?
> \.
> -- Lo digo porque si tiene que buscar DNI: me extraña que la columna
> sea simplemente "los digitos del dni con alguna cosa mas".
>
> Francisco Olarte:
>
> -
> 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
>



-- 
Cordialmente,

Ing. Hellmuth I. Vargas S.

Re: [pgsql-es-ayuda] Consulta sobre Split

[Hellmuth Vargas]

Hola Mario

Creo que tiene la misma situación que yo, le reenvío la respuesta en mi
caso




-- Mensaje reenviado --
De: "Hellmuth Vargas" <hiv...@gmail.com>
Fecha: 8 mar. 2017 3:27 PM
Asunto: Re: [pgsql-es-ayuda] no aplica constraint_exclusion con
concadenacion de parametros
Para: "Jaime Casanova" <jaime.casan...@2ndquadrant.com>
Cc: "Lista Postgres ES" <pgsql-es-ayuda@postgresql.org>

Hola Jaime

Muchas gracias por la respuesta Pues esta tabla se emplea en muchas
consultas (reportes) con diferentes joins y condiciones, por lo tanto no
seria factible una función, voy a ver que podemos hacer desde jasper para
enviar la fecha como una constante

El 7 de marzo de 2017, 19:35, Jaime Casanova<jaime.casan...@2ndquadrant.com>
escribió:

> On 7 March 2017 at 18:02, Hellmuth Vargas <hiv...@gmail.com> wrote:
> >
> > Tengo un servidor PostgreSQL 9.6 en le cual implemente particionamiento
> (por
> > fecha) sobre una tabla, pues sobre esta tabla se generan reportes
> mensuales
> > de gran cantidad de registros, ajuste el parámetro constraint_exclusion
> = on
> > para qeu excluyera las tablas que no estan en le rango, Hice una prueba y
> > funciona como se espera:
> >
> [...]
> >
> > Pero si cambio el formato de la  fechas (porque realmente esta consulta
> esta
> > dentro de un jasper y las fechas son parámetros y por lo tanto se
> > concadenan):
> >
>
> Esto funciona así desde siempre y la explicación es que postgres
> decide que particiones leer antes de llegar al executor (no recuerdo
> si en tiempo de parsing o planning, creería que en el segundo).
>
> Debido a que la consulta aun no empieza a ejecutarse (porque eso
> ocurre, obviamente, en el executor) postgres no ha resuelto funciones
> ni expresiones y por lo tanto no puede decidir eliminar particiones
> basándose en eso.
>
> La condición para que excluya particiones *tiene* que ser una
> constante. La única solución real, si es que no puedes enviar la fecha
> armada, es que escondas la consulta en una función almacenada usando
> SQL dinamico y concatenes lo que envias como una constante usando algo
> parecido a una función como la que te pongo de ejemplo (la cual tiene
> cabos sueltos):
>
>
> CREATE OR REPLACE FUNCTION consulta_dinamica(v_fecha_i text, v_hora_i
> text, v_fecha_f text, v_hora_f text)
>  RETURNS algo AS
> $$
>begin
>EXECUTE 'SELECT q.evento,count(*)
>   FROM queue_log q
>WHERE q.fecha  BETWEEN cast(' || v_fecha_i || '
> ' || v_hora_i || ' as timestamp )
>  AND   cast('
> || v_fecha_f || ' ' || v_hora_f || ' as timestamp )
> GROUP BY 1';
>   end;
> $$
> LANGUAGE 'plpgsql';
>
>
> --
> Jaime Casanova  www.2ndQuadrant.com
> PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
>



-- 
Cordialmente,

Ing. Hellmuth I. Vargas S.



-- Mensaje reenviado --
De: "Mario Sileone (GM)" <msile...@gmail.com>
Fecha: 20 mar. 2017 6:35 PM
Asunto: [pgsql-es-ayuda] Consulta sobre Split
Para: "pgsql-es-ayuda" <pgsql-es-ayuda@postgresql.org>
Cc:

Estimados, buenas noches.

Tengo una consulta respecto a las tablas divididas. Tenemos una
división en tablas que tienen millones de registros diarios, en tablas
heredadas mensuales.

Todo funciona de maravillas, salvo que, hemos notado que las consultas con
variables (between now() - interval '8 hours' AND now()) no hacen caso y
busca en todas las tablas heredadas.

Lo vimos en un explain con las variables y luego uno con las fechas
literales.

La pregunta es, al margen que tenemos la solución mediante código, si
existe algun método o quizás un quote_literal que transforme la consulta a
literal o alguna manera para que el postgres la interprete como tal.

Desde ya muchas gracias!

Saludos



-
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] configuración para disponer recovery_min_apply_delay en una replica

[Hellmuth Vargas]

Hola Lista

Tengo un servidor Master y dos replicas asincronicas  en la versión 9.5 de
PostgreSQL, en una de las  replicas quiero  establecer un delay de 2 horas
con respecto a la master, para estos leí que se podría establecer el
parámetro recovery_min_apply_delay  en el archivo recovery.conf de la  replica
que quiero retrasar, pero tengo las siguientes dudas:

1. Los WAL generados en la master se van a almacenar en la replica mientras
puede aplicarlos, por lo tanto tengo que disponer de mas espacio en disco
en la replica?

o

La  replica va a solicitar los WAL a las master con 2 horas de retraso por
lo tanto tendría que disponer de un mayor espacio en la master y además
ajustar parámetros como wal_keep_segments

2. Si eventualmente la replica retrasada se debe promover a master, estaría
retrasada en el tiempo o al promoverla aplicaría los cambios que harían
 falta para quedar a día con la ultima transacción confirmada y recibida en
los WAL?

Gracias Lista

-- 
Cordialmente,

Ing. Hellmuth I. Vargas S.

Re: [pgsql-es-ayuda] no aplica constraint_exclusion con concadenacion de parametros

[Hellmuth Vargas]

Hola Jaime

Muchas gracias por la respuesta Pues esta tabla se emplea en muchas
consultas (reportes) con diferentes joins y condiciones, por lo tanto no
seria factible una función, voy a ver que podemos hacer desde jasper para
enviar la fecha como una constante

El 7 de marzo de 2017, 19:35, Jaime Casanova<jaime.casan...@2ndquadrant.com>
escribió:

> On 7 March 2017 at 18:02, Hellmuth Vargas <hiv...@gmail.com> wrote:
> >
> > Tengo un servidor PostgreSQL 9.6 en le cual implemente particionamiento
> (por
> > fecha) sobre una tabla, pues sobre esta tabla se generan reportes
> mensuales
> > de gran cantidad de registros, ajuste el parámetro constraint_exclusion
> = on
> > para qeu excluyera las tablas que no estan en le rango, Hice una prueba y
> > funciona como se espera:
> >
> [...]
> >
> > Pero si cambio el formato de la  fechas (porque realmente esta consulta
> esta
> > dentro de un jasper y las fechas son parámetros y por lo tanto se
> > concadenan):
> >
>
> Esto funciona así desde siempre y la explicación es que postgres
> decide que particiones leer antes de llegar al executor (no recuerdo
> si en tiempo de parsing o planning, creería que en el segundo).
>
> Debido a que la consulta aun no empieza a ejecutarse (porque eso
> ocurre, obviamente, en el executor) postgres no ha resuelto funciones
> ni expresiones y por lo tanto no puede decidir eliminar particiones
> basándose en eso.
>
> La condición para que excluya particiones *tiene* que ser una
> constante. La única solución real, si es que no puedes enviar la fecha
> armada, es que escondas la consulta en una función almacenada usando
> SQL dinamico y concatenes lo que envias como una constante usando algo
> parecido a una función como la que te pongo de ejemplo (la cual tiene
> cabos sueltos):
>
>
> CREATE OR REPLACE FUNCTION consulta_dinamica(v_fecha_i text, v_hora_i
> text, v_fecha_f text, v_hora_f text)
>  RETURNS algo AS
> $$
>begin
>EXECUTE 'SELECT q.evento,count(*)
>   FROM queue_log q
>WHERE q.fecha  BETWEEN cast(' || v_fecha_i || '
> ' || v_hora_i || ' as timestamp )
>  AND   cast('
> || v_fecha_f || ' ' || v_hora_f || ' as timestamp )
> GROUP BY 1';
>   end;
> $$
> LANGUAGE 'plpgsql';
>
>
> --
> Jaime Casanova  www.2ndQuadrant.com
> PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
>



-- 
Cordialmente,

Ing. Hellmuth I. Vargas S.
Esp. Telemática y Negocios por Internet
Oracle Database 10g Administrator Certified Associate
EnterpriseDB Certified PostgreSQL 9.3 Associate

[pgsql-es-ayuda] no aplica constraint_exclusion con concadenacion de parametros

[Hellmuth Vargas]

Hola Lista

Tengo un servidor PostgreSQL 9.6 en le cual implemente particionamiento
(por fecha) sobre una tabla, pues sobre esta tabla se generan reportes
mensuales de gran cantidad de registros, ajuste el
parámetro constraint_exclusion = on para qeu excluyera las tablas que no
estan en le rango, Hice una prueba y funciona como se espera:


SELECT q.evento,count(*)
FROM queue_log q
WHERE q.fecha  BETWEEN cast('2017-02-01  00:00:00' as timestamp ) AND
cast('2017-02-28 23:59:59' as timestamp)
GROUP BY 1

HashAggregate  (cost=208639.45..208639.51 rows=21 width=17) (actual
time=1090.049..1090.055 rows=17 loops=1)
  Group Key: q.evento
  ->  Append  (cost=0.08..208359.40 rows=280053 width=9) (actual
time=0.058..795.635 rows=529426 loops=1)
->  Index Scan using queue_log_idx3 on queue_log q
 (cost=0.08..208359.40 rows=280053 width=9) (actual time=0.056..406.195
rows=529426 loops=1)
  Index Cond: ((fecha >= '2017-02-01 00:00:00'::timestamp
without time zone) AND (fecha <= '2017-02-28 23:59:59'::timestamp without
time zone))
Planning time: 4.557 ms
Execution time: 1090.098 ms



Pero si cambio el formato de la  fechas (porque realmente esta consulta
esta dentro de un jasper y las fechas son parámetros y por lo tanto se
concadenan):

SELECT q.evento,count(*)
FROM queue_log q
WHERE q.fecha  BETWEEN cast('2017-02-01 ' || '  00:00:00' as timestamp )
AND cast('2017-02-28 23:59:59' as timestamp)
GROUP BY 1

El plan de ejecución:

HashAggregate  (cost=208929.85..208929.92 rows=21 width=17) (actual
time=1029.625..1029.633 rows=17 loops=1)
  Group Key: q.evento
  ->  Append  (cost=0.09..208649.71 rows=280147 width=9) (actual
time=0.044..734.454 rows=529426 loops=1)
->  Index Scan using queue_log_idx3 on queue_log q
 (cost=0.09..208359.40 rows=280053 width=9) (actual time=0.042..343.010
rows=529426 loops=1)
  Index Cond: ((fecha >= ('2017-02-01
 00:00:00'::cstring)::timestamp without time zone) AND (fecha <=
'2017-02-28 23:59:59'::timestamp without time zone))
->  Index Scan using queue_log_part_200904_fecha_idx on
queue_log_part_200904 q_1  (cost=0.06..3.06 rows=1 width=10) (actual
time=0.020..0.020 rows=0 loops=1)
  Index Cond: ((fecha >= ('2017-02-01
 00:00:00'::cstring)::timestamp without time zone) AND (fecha <=
'2017-02-28 23:59:59'::timestamp without time zone))
->  Index Scan using queue_log_part_200905_fecha_idx on
queue_log_part_200905 q_2  (cost=0.06..3.06 rows=1 width=10) (actual
time=0.007..0.007 rows=0 loops=1)
  Index Cond: ((fecha >= ('2017-02-01
 00:00:00'::cstring)::timestamp without time zone) AND (fecha <=
'2017-02-28 23:59:59'::timestamp without time zone))
->  Index Scan using queue_log_part_200906_fecha_idx on
queue_log_part_200906 q_3  (cost=0.06..3.06 rows=1 width=10) (actual
time=0.006..0.006 rows=0 loops=1)
  Index Cond: ((fecha >= ('2017-02-01
 00:00:00'::cstring)::timestamp without time zone) AND (fecha <=
'2017-02-28 23:59:59'::timestamp without time zone))
->  Index Scan using queue_log_part_200907_fecha_idx on
queue_log_part_200907 q_4  (cost=0.06..3.06 rows=1 width=10) (actual
time=0.006..0.006 rows=0 loops=1)
  Index Cond: ((fecha >= ('2017-02-01
 00:00:00'::cstring)::timestamp without time zone) AND (fecha <=
'2017-02-28 23:59:59'::timestamp without time zone))
->  Index Scan using queue_log_part_200908_fecha_idx on
queue_log_part_200908 q_5  (cost=0.08..3.09 rows=1 width=10) (actual
time=0.007..0.007 rows=0 loops=1)
  Index Cond: ((fecha >= ('2017-02-01
 00:00:00'::cstring)::timestamp without time zone) AND (fecha <=
'2017-02-28 23:59:59'::timestamp without time zone))
->  Index Scan using queue_log_part_200909_fecha_idx on
queue_log_part_200909 q_6  (cost=0.08..3.09 rows=1 width=10) (actual
time=0.007..0.007 rows=0 loops=1)
  Index Cond: ((fecha >= ('2017-02-01
 00:00:00'::cstring)::timestamp without time zone) AND (fecha <=
'2017-02-28 23:59:59'::timestamp without time zone))
->  Index Scan using queue_log_part_200910_fecha_idx on
queue_log_part_200910 q_7  (cost=0.08..3.09 rows=1 width=10) (actual
time=0.006..0.006 rows=0 loops=1)
  Index Cond: ((fecha >= ('2017-02-01
 00:00:00'::cstring)::timestamp without time zone) AND (fecha <=
'2017-02-28 23:59:59'::timestamp without time zone))
->  Index Scan using queue_log_part_200911_fecha_idx on
queue_log_part_200911 q_8  (cost=0.08..3.09 rows=1 width=10) (actual
time=0.006..0.006 rows=0 loops=1)
  Index Cond: ((fecha >= ('2017-02-01
 00:00:00'::cstring)::timestamp without time zone) AND (fecha <=
'2017-02-28 23:59:59'::timestamp without time zone))
->  Index Scan using queue_log_part_200912_fecha_idx on
queue_log_part_200912 q_9  (cost=0.08..3.09 rows=1 width=10) (actual
time=0.007..0.007 rows=0 loops=1)
  Index Cond: ((fecha >= ('2017-02-01
 00:00:00'::cstring)::timestamp without time zone) AND (fecha <=
'2017-02-28 

Re: [pgsql-es-ayuda] bug al agrupar postgres 9.5 y 9.6?

[Hellmuth Vargas]

Hola Alvaro

Gracias por la respuesta; si tiene razon: agrupe solo por id y siguió
funcionado... :-)


select a.id,a.identificacion,fechaactivacion,min(b.fecha) as minima from
usuario as a join adherencia as b on a.id=b.usuario_id
group by 1



HashAggregate  (cost=2217.64..2220.74 rows=1035 width=34) (actual
time=240.780..241.232 rows=941 loops=1)
  Output: a.id, a.identificacion, a.fechaactivacion, min(b.fecha)
  Group Key: a.id
  Buffers: shared hit=91 read=1204
  ->  Hash Join  (cost=92.73..2099.46 rows=118182 width=34) (actual
time=1.659..175.634 rows=121101 loops=1)
Output: a.id, a.identificacion, a.fechaactivacion, b.fecha
Hash Cond: (b.usuario_id = a.id)
Buffers: shared hit=91 read=1204
->  Seq Scan on adherencia b  (cost=0.00..1563.55 rows=118182
width=16) (actual time=0.039..58.533 rows=121101 loops=1)
  Output: b.id, b.fecha, b.termina, b.tiempoadherido, b.inicia,
b.usuario_id, b.pausaactual_id
  Buffers: shared hit=5 read=1204
->  Hash  (cost=89.11..89.11 rows=1035 width=26) (actual
time=1.608..1.608 rows=1035 loops=1)
  Output: a.id, a.identificacion, a.fechaactivacion
  Buckets: 2048  Batches: 1  Memory Usage: 69kB
  Buffers: shared hit=86
  ->  Seq Scan on usuario a  (cost=0.00..89.11 rows=1035
width=26) (actual time=0.010..1.021 rows=1035 loops=1)
Output: a.id, a.identificacion, a.fechaactivacion
Buffers: shared hit=86
Planning time: 0.220 ms
Execution time: 241.635 ms




El 16 de febrero de 2017, 11:46, Alvaro Herrera<alvhe...@2ndquadrant.com>
escribió:

> Hellmuth Vargas escribió:
> > Hola Lista
> >
> > Al ejecutar la siguiente consulta sin agrupar por el campo
> fechaactivacion
> > uno esperaria el siguiente error:
> >
> > ERROR:  column "a.fechaactivacion" must appear in the GROUP BY clause or
> be
> > used in an aggregate function
> >
> > Pero oh sorpresa, me lleve cuando el motor la ejecuto  de forma
> > satisfactoria.
>
> Funciona porque el sistema sabe que "id" es llave primaria de la tabla
> a, por lo tanto fechaactivación (de la misma tabla) tiene necesariamente
> que ser un único valor por grupo.
>
> > Trate de recrearlo con tablas en memoria (SELECT * from (VALUES())..)
> pero
> > si genera error a no agrupar por el campo *fechaactivacion*.
>
> Acá no funciona porque no hay llave primaria que permita hacer la
> deducción.
>
> --
> Álvaro Herrerahttps://www.2ndQuadrant.com/
> PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
>



-- 
Cordialmente,

Ing. Hellmuth I. Vargas S.
Esp. Telemática y Negocios por Internet
Oracle Database 10g Administrator Certified Associate
EnterpriseDB Certified PostgreSQL 9.3 Associate

[pgsql-es-ayuda] bug al agrupar postgres 9.5 y 9.6?

[Hellmuth Vargas]

Hola Lista

Al ejecutar la siguiente consulta sin agrupar por el campo fechaactivacion
uno esperaria el siguiente error:

ERROR:  column "a.fechaactivacion" must appear in the GROUP BY clause or be
used in an aggregate function

Pero oh sorpresa, me lleve cuando el motor la ejecuto  de forma
satisfactoria. La verifique tanto en PostgreSQL 9.5 (PostgreSQL 9.5.4) como
en PostgreSQL 9.6 (PostgreSQL 9.6.1) y en ambos funciona igual


select a.id,a.identificacion,*fechaactivacion*,min(b.fecha) as minima from
usuario as a join adherencia as b on a.id=b.usuario_id
*group by 1,2*


Explain analyze:

HashAggregate  (cost=3472.35..3478.14 rows=1447 width=34) (actual
time=144.138..144.415 rows=1359 loops=1)
  Output: a.id, a.identificacion, *a.fechaactivacion*, min(b.fecha)
  Group Key: *a.id , a.identificacion*
  Buffers: shared hit=76 read=1788
  ->  Hash Join  (cost=314.30..3238.78 rows=155712 width=34) (actual
time=10.179..91.949 rows=155886 loops=1)
Output: a.id, a.identificacion, a.fechaactivacion, b.fecha
Hash Cond: (b.usuario_id = a.id)
Buffers: shared hit=76 read=1788
->  Seq Scan on adherencia b  (cost=0.00..2184.85 rows=155712
width=16) (actual time=0.490..30.102 rows=155886 loops=1)
  Output: b.id, b.fecha, b.inicia, b.termina, b.tiempoadherido,
b.pausaactual_id, b.usuario_id
  Buffers: shared hit=9 read=1553
->  Hash  (cost=307.79..307.79 rows=1447 width=26) (actual
time=9.453..9.453 rows=1447 loops=1)
  Output: a.id, a.identificacion, a.fechaactivacion
  Buckets: 2048  Batches: 1  Memory Usage: 89kB
  Buffers: shared hit=67 read=235
  ->  Seq Scan on usuario a  (cost=0.00..307.79 rows=1447
width=26) (actual time=0.019..2.465 rows=1447 loops=1)
Output: a.id, a.identificacion, a.fechaactivacion
Buffers: shared hit=67 read=235
Planning time: 1.593 ms
Execution time: 144.532 ms

Trate de recrearlo con tablas en memoria (SELECT * from (VALUES())..) pero
si genera error a no agrupar por el campo *fechaactivacion*. La estructura
 básica de las tablas son:

CREATE TABLE usuario
(
  dtype character varying(31) NOT NULL,
  id bigint NOT NULL,
  identificacion character varying(255),
  login character varying(255) NOT NULL,
  apellidos character varying(255),
  nombres character varying(255),
  estado character varying(255),
  bytepassword oid,
  email character varying(255),
  encodedpassword character varying(255),
  fechacreacion timestamp without time zone,
  fechamodificacion timestamp without time zone,
  idusuariocrea bigint,
  idusuariomodifica bigint,
  modologueoobligatorio boolean,
  tipoagente character varying(255),
  codigoexterno character varying(255),
  deleted boolean NOT NULL DEFAULT false,
  fechaactivacion timestamp without time zone,
  tipocuenta character varying(255),
  encodedsegundadclave character varying(255),
  CONSTRAINT usuario_pkey PRIMARY KEY (id),
  CONSTRAINT usuario_login_key UNIQUE (login),
  CONSTRAINT usuario_numeroagente_key UNIQUE (numeroagente)
)

--

CREATE TABLE adherencia
(
  id bigint NOT NULL,
  fecha timestamp without time zone NOT NULL,
  termina timestamp without time zone,
  tiempoadherido bigint,
  inicia timestamp without time zone NOT NULL,
  usuario_id bigint NOT NULL,
  pausaactual_id bigint,
  CONSTRAINT adherencia_pkey PRIMARY KEY (id)
)



-- 
Cordialmente,

Ing. Hellmuth I. Vargas S.
Esp. Telemática y Negocios por Internet

Re: [pgsql-es-ayuda] Requisitos para instalacion de postgres en windows

[Hellmuth Vargas]

Buenos días

Apelando a la documentación  se puede encontrar los siguientes requisitos
para instalación de la ultima versión, la 9.6:

2.1 Hardware Requirements
The following installation requirements assume you have selected the
default options during the installation process. The minimum hardware
required to install and run PostgreSQL are:

1 GHz processor
1 GB of RAM
512 MB of HDD *

2.2 Software Prerequisites


(..)If you are installing PostgreSQL into a Windows system that is
configured with User Account Control (UAC) enabled, you can assume
sufficient privileges to invoke the graphical installer by right clicking
on the name of the installer and selecting Run as administrator from the
context menu. If prompted, enter an administrator password to continue.(..)


http://get.enterprisedb.com/docs/PostgreSQL_Installation_Guide_v9.6.pdf

Siempre es recomendable instalar la ultima versión disponible, esto es para
aprovechar, por un lado, las nuevas funcionalidades y por otro la solución
de errores. Lo que si se debe realizar, una vez concluida la instalaron, es
una configuración de los parámetros del motor para que se adecue a las
capacidades del entorno donde va a ejecutarse y así obtener el desempeño
correspondiente a los recursos disponibles.






El 8 de febrero de 2017, 16:27, jvenegasperu .
escribió:

> Hola Maria Antonieta
>
> Si te refieres a requerimientos minimos pues con un un pc con 1.7 Gb de
> RAM puedes instalar hasta postgres 9.5 sin problemas. sobre windows server
> 2008
>
> Si es para hacer solo pruebas estara bien pero si lo necesitas para
> trabajo real dependera del tamaño y de tus tablas la cantidad de
> transacciones etc.
>
> Por ejemplo yo recientemente he montado un postgres 9.5.5 sobre un windows
> server 2012 con solo 1.7 Gb de RAM
>
> luego dentro puse dos tablas una con 3 Gb de y otra con 2 Gb de peso e
> hice una actualizacion de 16 millones de registros se tardo 63.5 horas
> jejeje.
>
> pienso que eso paso porque no se podian colocar los indices en memoria
> para usarlos menos mal que eso lo voy a usar solo para hacer una consulta
> individual de un registro y ahi si responde de manera instantanea
>
> Espero esto te de una idea de lo que necesitas
>
> Comento que solo hasta postgres 9.5.5 porque tambien probe con postgres
> 9.6.1 y respondia super lentium jejej asi que lo borre instale postgres
> 9.5.5 y esta funcionando con normalidad.
>
> Saludos
>
>
>
>
>
> El 8 de febrero de 2017, 16:15, Mario Jiménez Carrasco <
> mario.carra...@gmail.com> escribió:
>
>> Hola Maria Antonieta...
>> Creo que te podrían ayudar más, si pudieras dar mas datos sobre el tipo
>> de base de datos, la cantidad de información que vas a almacenar, la
>> demanda de consultas/escrituras que tendrá, entre otros elementos, ya que
>> de eso depende el hardware y los complementos.
>>
>> Saludos.
>>
>> ISC. Mario Jiménez Carrasco.
>> Subdirección Técnico y de Negocios
>> Desarrollo de Software.
>> Gobierna SCP.
>>
>> 2017-02-08 13:20 GMT-06:00 Maria Antonieta Ramirez <
>> marami...@ulsaneza.edu.mx>:
>>
>>>
>>> Buena tarde
>>>
>>>
>>> De ante mano gracias por su tiempo, alguien me podria decir donde veo
>>> los prerequisitos de software y hardware para instalar postgres 9.4 en un
>>> servidor windows server 2008 R2.
>>>
>>>
>>> Sin mas por el momento quedo en espera de sus comentarios.
>>>
>>>
>>> Gracias.
>>>
>>>
>>>
>>
>
>
> --
> José Mercedes Venegas Acevedo
> cel Mov RPC 964185205
>
> skype jvenegasperu
> facebook jvenegasperu
> 
>



-- 
Cordialmente,

Ing. Hellmuth I. Vargas S.
Esp. Telemática y Negocios por Internet
Oracle Database 10g Administrator Certified Associate
EnterpriseDB Certified PostgreSQL 9.3 Associate

Re: [pgsql-es-ayuda] autovacuum excesivo PostgreSQL 9.5

[Hellmuth Vargas]

Hola Alvaro

Muchas gracias por la respuesta...  Finalmente,  todas las réplicas que
tenía configurados slot y hot_standby_feedback en ON hacían que sus
correspondientes máster quedarán haciendo autovacuum "permanentementes" por
lo tanto se estableció hot_standby_feedback en OFF y se soluciono el tema.


El 9 ene. 2017 9:53 AM, "Alvaro Herrera" <alvhe...@2ndquadrant.com>
escribió:

Hellmuth Vargas escribió:
> Hola Alvaro
>
> Hice lo que sumrece me indico:
>
> - Borre el replication Slot
> - Comentarie # primary_slot_name = 'replica_local_slot' del archivo
> recovery.conf en la replica y reinicie la misma para  que tomara el cambio
> - Realice un vacuum sobre la tabla marcador
>
> INFO:  vacuuming "sac.marcador"
> INFO:  "marcador": found 1074892 removable, 1505259 nonremovable row
> versions in 105572 pages
> DETAIL:  35 dead row versions cannot be removed yet.
> CPU 0.65s/5.76u sec elapsed 9.17 sec.
> INFO:  analyzing "sac.marcador"
> INFO:  "marcador": scanned 59833 of 59833 pages, containing 1505224 live
> rows and 53 dead rows; 12 rows in sample, 1505224 estimated total rows
> Query returned successfully with no result in 17.4 secs.
>
> Y santo remedio!!!
>
> pero me queda las siguientes dudas?
>
> - Puedo volver a disponer un replication slot para esta replica?
> - O  debo colocar hot_standby_feedback  en OFF en la replica?

Hola, no había visto este correo.  Me parece que si tienes
hot_standby_feedback no necesitas el replication slot, y tienes un slot,
no necesitas hot_standby_feedback.  Con uno solo de los dos mecanismos
es suficiente.  Ambos hacen lo mismo: impedir que el master recicle
(borre) WAL que la réplica todavía necesita.  El standby feedback sólo
funciona cuando la réplica está conectada, en cambio el slot funciona
siempre, incluso si borras la réplica (y entonces tienes que asegurarte
de borrar el slot cuando la réplica deja de usarlo).  El problema del
feedback es que si la réplica se desconecta por un tiempo largo, el
maestro podría borrar el WAL, creo.

El hot_standby_feedback es código más antiguo, en cambio los slots
recién se inventaron en Postgres 9.4 ó 9.5.  Yo usaría un slot, que es
más seguro, pero agregaría en el monitoreo del sistema un seguimiento de
qué tan atrasados están los slots.  Así, cuando en el futuro una réplica
tenga problemas ya sabrán que hay que borrar un slot, antes de que se
convierta en un problema serio.

Saludos

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

Re: [pgsql-es-ayuda] ERROR: requested WAL segment XXXXX has already been removed

[Hellmuth Vargas]

hola Lista

Como ya lo han comentando en la cadena de correos, cito "la replicacion fue
mas lenta que la generación de wals y el wal 000101BE00F1 fue
reciclado en el master antes de que se replicara en el esclavo", para esto
existen varias alternativas de configuración, algunas dependiendo de la
versión:

-  wal_keep_segments, este parámetro del postgresql.conf, establece una
cantidad de archivos WAL a conservar en el servidor (después que fueron
reciclados) para que los esclavos lentos  se puedan sincronizan. El
problema de este parámetro es que toca cuadrarlo a ojo: ni mucho para
gastar mucho espacio en el maestro ni poco que vuelva a tener un borrado de
un WAL.

 - habilitar archive, con esto puede almacenar una cantidad de archivos wal
en una carpeta de red que ambas maquinas puedan acceder (el maestro
escribiendo y el esclavo leyendo) y en el archivo recovery.conf del esclavo
 establecer el parámetro restore_command (y de paso
archive_cleanup_command), para que en le caso que el WAL no  estuviese
disponible por replicacion, se restaure desde la carpeta compartida de
archive, hay que tener una carpeta con espacio generoso  para almacenar
estos wal archivados, sobre todo en cargues grandes, vacuum,etc y hay que
diseñar  bien el mecanismo de retención si se cuentan con 2 o mas replicas

- replication_slot, desde la versión 9.4, es posible crear
replication_slot, que es un mecanismo mas eficiente para llevar la cuenta y
almacenar los wal que cada esclavo requiere para su sincronizacion, para
cada esclavo se crea un slot y en el archivo recovery.conf de la replica se
registra este slot generado.



Aveces es prudente combinar varias estrategias:  en mi caso, como mantengo
backups diarios en caliente, tengo configurado archive y ademas replication
slot y unos cuantos wal_keep_segments, :-)


El 3 de enero de 2017, 15:37, raul andrez gutierrez alejo<
rauland...@gmail.com> escribió:

> Hay un postgres (esclavo) que esta pidiendo un wal que ya no existe, no se
> que version de postgres tiene, pero puede ser que el cluster quedo
> configurado en cascada, master replica al esclavo1 y el esclavo1 replica al
> esclavo2, es posible que el postgres aun este corriendo en el eslcavo que
> se supone que ya no esta.
>
> o tambien se presento una promocion del master y el nuevo master estaba un
> poco atrazado en la replicacion y se presento una bifulcacion en los wals.
>
> verifique el log " requested WAL segment" y identifique cual es la ip de
> la conexion que esta pidiendo ese wal.
>
>
> El 3 de enero de 2017, 15:24, Alberto Cardenas Cardenas <
> alberto.cardenas.c...@gmail.com> escribió:
>
>> Gracias Raul por responder, pero no existe otra forma de eliminar ese
>> error???, las máquina a la que hacia referencia ese error, ya no es
>> esclava, es decir, habia dos esclavos y ahora hay uno, y el que está, esta
>> bien, ese error quedo de la otra máquina pero no se como elininarlo
>>
>> saludos
>>
>> El 3 de enero de 2017, 15:42, raul andrez gutierrez alejo <
>> rauland...@gmail.com> escribió:
>>
>>> hola Alberto.
>>>
>>> Para solucionar ese log, debe sincronizarzar nuevamente el esclavo con
>>> un pg_basebackup(), eso se dio porque la replicacion fue mas lenta que la
>>> generacion de wals y el wal 000101BE00F1 fue reciclado en
>>> el master antes de que se replicara en el esclavo.
>>>
>>>
>>>
>>> El 3 de enero de 2017, 14:31, Alberto Cardenas Cardenas <
>>> alberto.cardenas.c...@gmail.com> escribió:
>>>
 Estimada lista, antes que todo muchas felicidades y  que tengan todos
 un muy feliz año 2017.

 Ahora bien,tengo un problema, ¿que puedo hacer para que este mismo
 mensaje que se me repite desde hace un mes, ya no me siga apareciendo.?

 ERROR: requested WAL segment 000101BE00F1 has already been
 removed

 Todos los días en el log, veo este error. Como puedo eliminar este error

 Saludos cordiales

>>>
>>>
>>>
>>> --
>>> Raul Andres Gutierrez Alejo
>>>
>>
>>
>
>
> --
> Raul Andres Gutierrez Alejo
>



-- 
Cordialmente,

Ing. Hellmuth I. Vargas S.
Esp. Telemática y Negocios por Internet
Oracle Database 10g Administrator Certified Associate
EnterpriseDB Certified PostgreSQL 9.3 Associate

[pgsql-es-ayuda] Re: [pgsql-es-ayuda] Re: [pgsql-es-ayuda] Re: [pgsql-es-ayuda] Función con select se ejecutar muy lenta comparada con la ejecución de select fuera de la función

[Hellmuth Vargas]

Hola Lista


tengo una duda, Que tipo de dato es  id_articulo en la tabla d_articulo


El 21 de diciembre de 2016, 13:48, Ernesto Lozano
escribió:

> Gracias Jose porque no revisa el Log haber que tanto select e Insert
>
> Saludos
>
> Ernesto
>
>
>
> El 21 de diciembre de 2016, 14:36, Francisco Olarte <
> fola...@peoplecall.com> escribió:
>
>> 2016-12-21 19:10 GMT+01:00 "José Alberto Sánchez Nieto (Trabajo)"
>> :
>> ...
>> > que tengo un índice por ese campo y el tiempo de ejecución es 0.045ms
>> ...
>> > Y la ejecuto con: select prueba_velocidad(‘2097’) dándome unos tiempos
>> de
>> > 0.229ms
>>
>> Solo por confirmar, dado que los tiempos son muy pequeños, has probado
>> a cambiar el EXECUTE de la funcion por algo tipo
>>
>> EXECUTE ‘SELECT 1,2,3,4,5,' || quote_literal($1)
>>
>> Por ver cuanto tiempo se te lleva el tema de meterte y salirte de una
>> funcion?
>>
>> Francisco Olarte.
>>
>
>
>
> --
> Atentamente
> Ernesto Lozano
> Director General
> Hia Techonology Systems, C.A.
> www.hiatechnology.co.ve
> 0058 241 867.20.23
>
>
>


-- 
Cordialmente,

Ing. Hellmuth I. Vargas S.
Esp. Telemática y Negocios por Internet
Oracle Database 10g Administrator Certified Associate
EnterpriseDB Certified PostgreSQL 9.3 Associate

Re: [pgsql-es-ayuda] pg_xlog se puede inicializar ?

[Hellmuth Vargas]

Hola

Revise la herramienta pg_resetxlog

https://www.postgresql.org/docs/8.3/static/app-pgresetxlog.html

El 7 de diciembre de 2016, 05:12, Kernel escribió:

>
> hola,
> me he topado con un postgres 8.3 que no arranca.
> No tiene nada dentro del pg_xlog.
>
> SALIDA DEL LOG
>
> 2016-12-07 11:09:50 CET   LOG:  el sistema de bases de datos fue apagado
> en 2016-12-07 10:29:53 CET
> 2016-12-07 11:09:50 CET   LOG:  no se pudo abrir
> «pg_xlog/000100010032» (archivo de registro 1, segmento 50):
> No existe el fichero o el directorio
> 2016-12-07 11:09:50 CET   LOG:  el registro primario de checkpoint no es
> válido
> 2016-12-07 11:09:50 CET   LOG:  el enlace de checkpoint secundario en
> archivo de control no es válido
> 2016-12-07 11:09:50 CET   PANIC:  no se pudo localizar un registro de
> checkpoint válido
> 2016-12-07 11:09:50 CET   LOG:  proceso de inicio (PID 27336) fue
> terminado por una señal 6: Aborted
> 2016-12-07 11:09:50 CET   LOG:  abortando el inicio debido a una falla en
> el procesamiento de inicio
>
>
> Alguna manera de que arranque sin ello, ¿inicializarlo?
>
> 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
>



-- 
Cordialmente,

Ing. Hellmuth I. Vargas S.
Esp. Telemática y Negocios por Internet
Oracle Database 10g Administrator Certified Associate
EnterpriseDB Certified PostgreSQL 9.3 Associate

Re: [pgsql-es-ayuda] Consulta sobre replicacion

[Hellmuth Vargas]

Hola

Según creo entender:

- La arquitectura de la aplicación es que tiene una tabletas  desconectadas
donde se captura y consulta una informacion y luego se desea sincronizar
esta con un servidor central.

- Las tabletas tienen un PostgreSQL y el servidor central también tienen
PostgreSQL en la misma versión








El 24 de octubre de 2016, 14:29, Lazaro Garcia
escribió:

> No entendí muy bien tu explicación, tu sistema corre sobre un Tablet(capa
> de presentación) que se conecta a uno o varios servers remotos donde corre
> tu capa de aplicación con tus servidores de base de datos o la base la
> quieres montar en cada uno de los tablets que tienes??
>
>
>
> Saludos.
>
>
>
> *De:* pgsql-es-ayuda-ow...@postgresql.org [mailto:pgsql-es-ayuda-owner@
> postgresql.org] *En nombre de *Carlos Enrique Perez
> *Enviado el:* lunes, 24 de octubre de 2016 3:20
> *Para:* PostgreSQL Lista Castellano
> *Asunto:* [pgsql-es-ayuda] Consulta sobre replicacion
>
>
>
> Estimados:
>
> Necesito trabajar en un caso particular con replicacion y necesito
> recomendaciones:
>
>
>
> Regla de negocio:
>
> . Salen vendedores con mercaderia en consignacion a lugares remotos. Para
> ellos, los dueños se decidieron por una tablet con windows. Instalamos
> postgres y el sistema que esta en java con jboss.
>
>
>
> . Tienen un server del cual queremos que sea el MASTER y las tables los
> SLAVE.
>
>
>
> Me ayudan a seleccionar la herramienta adecuada y si tienen algunos
> ejemplos que sirvan?
>
> desde ya mil gracias.
>
>
>



-- 
Cordialmente,

Ing. Hellmuth I. Vargas S.
Esp. Telemática y Negocios por Internet
Oracle Database 10g Administrator Certified Associate
EnterpriseDB Certified PostgreSQL 9.3 Associate

Re: [pgsql-es-ayuda] Cambiar motor de disco en Ubuntu

[Hellmuth Vargas]

Hola Jose

Unas preguntas:

- Necesita migrar la base de datos a un nuevo disco de mayor
capacidad/mejores prestaciones?
- Que nivel de servicio tiene la base de datos: 7x24 o solo horario hábil?
- Que versión de base de datos tiene actualmente, si es una versión
anterior, hay posibilidades de actualizar la versión?
- Tiene replicación implementada?







El 11 de octubre de 2016, 13:18, Alvaro Herrera
escribió:

> Francisco Olarte escribió:
> > Buenas tardes:
> >
> > 2016-10-07 23:15 GMT+02:00 Electricos del Valle S.A. - Jose Fdo Donado
> > E. :
> > >
> > > Tengo instalado Postgresql en Ubuntu y quisiera pasar todo el motor a
> un disco nuevo, me pueden indicar como se hace.
> >
> > Sin mas detalles como que sera imposible ayudarte. Necesitaras contar
> > al menos que discos montas y en que puntos y en que directorios has
> > metido las cosas de postgres, y ademas en Ubuntu creo que tienes la
> > complejidad añadida de que usa los wrappers de Martin Pitt, que no es
> > un postgres a secas.
>
> Es posible que sea suficiente con crear un directorio en el nuevo disco,
> luego darle un CREATE TABLESPACE, y finalmente ALTER TABLE .. SET
> TABLESPACE bla.  No necesitas parar el servidor, aunque obviamente las
> tablas quedan bloqueadas mientras se efectúa la copia.
>
> --
> Álvaro Herrerahttps://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
>



-- 
Cordialmente,

Ing. Hellmuth I. Vargas S.
Esp. Telemática y Negocios por Internet
Oracle Database 10g Administrator Certified Associate
EnterpriseDB Certified PostgreSQL 9.3 Associate

Re: [pgsql-es-ayuda] campos timestamp

[Hellmuth Vargas]

Hola Lista

Hice el siguuiente ejercicio:

select cast('1968-09-08 00:00:00+01' as timestamp) as
fecha,cast('1900-01-01 10:00:00+00' as timestamp) as hora, cast('1968-09-08
00:00:00+01' as timestamp)+cast(cast('1900-01-01 10:00:00+00' as timestamp)
as time) as fechahora



El 6 de octubre de 2016, 03:59, Francisco Olarte
escribió:

> Buenos dias:
>
> 2016-10-06 10:00 GMT+02:00 Magi Franquesa :
> > Tengo una bd con registros de incendios en los que se indica la fecha y
> hora
> > de inicio en un campo de tipo "timestamp with time zone", pero el
> problema
> > es que en lugar de un solo campo con ambos datos hay dos campos: uno que
> > contiene la fecha correcta y el segundo la hora. Necesito crear un nuevo
> > campo del mismo tipo con la fecha y hora como muestro en el ejemplo
> > siguiente:
> >
> > Campo 1 (fecha inicio):"1968-09-08 00:00:00+01"
> > Campo 2 (hora inicio): "1900-01-01 10:00:00+00"
> > Resultado buscado: "1968-09-08 10:00:00+00"
>
> Quieres extraer la ZONA HORARIA del registro 2? Eso depende mucho de
> tu base de datos de zonas y de tu zona de cliente predeterminada, a mi
> por ejemplo me pasa esto:
>
>
> n=> with base as (select '1968-09-08 00:00:00+01'::timestamp with time
> zone as ts_fecha,
> '1900-01-01 10:00:00+00'::timestamp with time zone as ts_hora)
> select * from base;
> ts_fecha|   ts_hora
> +--
>  1968-09-08 00:00:00+01 | 1900-01-01 09:45:16-00:14:44
>
> Porque si, en España parece ser que por aquella epoca llevabamos el
> meridiano de Madrid, o algo asi, porque 14min:44 segs, ya que una hora
> son 15 grados de latitud, y 15*(14/60+44/3600)=3.68, .68*60 ~=
> 41, 3-41W que es la puerta del Sol, calle arriba calle abajo.
>
> Tienes varias formas de pegar eso, una es a lo burro en texto, jugando
> con substrings. Otra puede ser extrayendo las fechas y horas mediante
> casts:
>
>
> newtron=> with base as (select '1968-09-08 00:00:00+01'::timestamp
> with time zone as ts_fecha,
> '1900-01-01 10:00:00+00'::timestamp with time zone as ts_hora)
> select cast(ts_fecha as date) , cast(ts_hora as time with time zone) from
> base;
>   ts_fecha  |  ts_hora
> +---
>  1968-09-08 | 09:45:16-00:14:44
> (1 row)
>
>  Que solo con sumarse te da un resultado, pero puede no ser lo que quieres:
>
> newtron=> with base as (select '1968-09-08 00:00:00+01'::timestamp
> with time zone as ts_fecha,
> '1900-01-01 10:00:00+00'::timestamp with time zone as ts_hora)
> select cast(ts_fecha as date) + cast(ts_hora as time with time zone) from
> base;
> ?column?
> 
>  1968-09-08 11:00:00+01
> (1 row)
>
> FIJATE que la rutina de salida de la fecha te lo da en la hora que
> estaba en efecto en esa epoca, si quieres FORMATEARLO en UTC no tienes
> mas que hacer:
>
> newtron=> set timezone to 'UTC';
>
> PERO entonces tienes el problema de que el cast intermedio a DATE te
> lo pasa por UTC y no te da lo que buscas:
>
> newtron=> with base as (select '1968-09-08 00:00:00+01'::timestamp
> with time zone as ts_fecha,
> '1900-01-01 10:00:00+00'::timestamp with time zone as ts_hora)
> select cast(ts_fecha as date) + cast(ts_hora as time with time zone) from
> base;
> ?column?
> 
>  1968-09-07 10:00:00+00
> (1 row)
>
> Con lo que igual tienes que pasarlo a sin-timezone:
>
> newtron=> with base as (select '1968-09-08 00:00:00+01'::timestamp
> with time zone as ts_fecha,
> '1900-01-01 10:00:00+00'::timestamp with time zone as ts_hora)
> select (cast(ts_fecha as date) + cast(ts_hora as time with time zone))
> at time zone 'UTC' from base;
>   timezone
> -
>  1968-09-08 10:00:00
> (1 row)
>
> En general el problema es complicado, dado que los ts WITH tz designan
> un instante en el tiempo, convertirlos como tu quieres a FECHAS es
> imposible sin saber en que zona horaria estaban originalmente.
> Normalmente la forma correcta es pasar de ts WITH tz a WITHOUT tz, que
> ya no tiene problemas, operar ahi y luego reconvertir de vuelta, p.e.:
>
> newtron=> with base as (select '1968-09-08 00:00:00+01'::timestamp
> with time zone as ts_fecha,
> '1900-01-01 10:00:00+00'::timestamp with time zone as ts_hora)
> select (cast(ts_fecha at time zone 'Europe/Madrid' as date) +
> cast(ts_hora at time zone 'UTC' as time)) at time zone 'UTC' from
> base;timezone
> 
>  1968-09-08 11:00:00+01
> (1 row)
>
> Observa que me sale en el horario mio ( Madrid ), si exploras las
> partes veras que el proceso es, primero sacar una fecha y hora sin
> zonas:
>
> newtron=> with base as (select '1968-09-08 00:00:00+01'::timestamp
> with time zone as ts_fecha,
> '1900-01-01 10:00:00+00'::timestamp with time zone as ts_hora)
> select cast(ts_fecha at time zone 'Europe/Madrid' as date),
> cast(ts_hora at time zone 'UTC' as time) from base;
>   timezone  | timezone
> 

Re: [pgsql-es-ayuda] autovacuum excesivo PostgreSQL 9.5

[Hellmuth Vargas]

Hola Alvaro

Hice lo que sumrece me indico:

- Borre el replication Slot
- Comentarie # primary_slot_name = 'replica_local_slot' del archivo
recovery.conf en la replica y reinicie la misma para  que tomara el cambio
- Realice un vacuum sobre la tabla marcador

INFO:  vacuuming "sac.marcador"
INFO:  "marcador": found 1074892 removable, 1505259 nonremovable row
versions in 105572 pages
DETAIL:  35 dead row versions cannot be removed yet.
CPU 0.65s/5.76u sec elapsed 9.17 sec.
INFO:  analyzing "sac.marcador"
INFO:  "marcador": scanned 59833 of 59833 pages, containing 1505224 live
rows and 53 dead rows; 12 rows in sample, 1505224 estimated total rows
Query returned successfully with no result in 17.4 secs.

Y santo remedio!!!

pero me queda las siguientes dudas?

- Puedo volver a disponer un replication slot para esta replica?
- O  debo colocar hot_standby_feedback  en OFF en la replica?

Muchas gracias Alvaro por todo su tiempo ! :-)




El 4 de octubre de 2016, 08:50, Alvaro Herrera<alvhe...@2ndquadrant.com>
escribió:

> Hellmuth Vargas escribió:
> > Hola Alvaro
> >
> > No se si se me cruzaron las terminales!! reenvio todas las consultas y/o
> > pantallas para verificar y si el es caso mil disculpas:
>
> OK.  Así tiene que haber sido ... los datos que das ahora son
> diferentes.  Lo importante considerar es acá:
>
> > [postgres@MDB ~]# pg_controldata -D /PostgreSQL/9.5/data
>
> > Latest checkpoint's NextXID:  0/8406787
>
> > bd=# select * from pg_replication_slots;
> >
> > -[ RECORD 2 ]+-
> > slot_name| replica_local_slot
> > plugin   |
> > slot_type| physical
> > datoid   |
> > database |
> > active   | t
> > active_pid   | 2054
> > xmin | 5463120
> > catalog_xmin |
> > restart_lsn  | 9/3670A150
>
> En este slot el xmin es 5 millones, que es muy anterior a los 8 millones
> que es el valor actual del contador de transacciones.  Es importante
> hacer que ese slot se mueva; si la aplicación que lo usaba se murió,
> entonces hay que eliminarlo.  Puedes fijarte qué lo está usando buscando
> un proceso con PID 2054, y ver si está conectado y a quién.  Si no tiene
> uso, dale un
>   select * from pg_drop_replication_slot('replica_local_slot')
>
> y luego vuelve a probar vacuum.
>
> --
> Álvaro Herrerahttps://www.2ndQuadrant.com/
> PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
>



-- 
Cordialmente,

Ing. Hellmuth I. Vargas S.
Esp. Telemática y Negocios por Internet
Oracle Database 10g Administrator Certified Associate
EnterpriseDB Certified PostgreSQL 9.3 Associate

Re: [pgsql-es-ayuda] autovacuum excesivo PostgreSQL 9.5

[Hellmuth Vargas]

lreceiver
client_addr  | 192.168.72.XX
client_hostname  |
client_port  | 46730
backend_start| 2016-10-03 23:23:35.355306-05
backend_xmin |
state| streaming
sent_location| 9/365B2E88
write_location   | 9/365B2E88
flush_location   | 9/365B2E88
replay_location  | 9/365B2C40
sync_priority| 0
sync_state   | async
-[ RECORD 2 ]+--
pid  | 2054
usesysid | 10
usename  | postgres
application_name | walreceiver
client_addr  | 10.72.73.XX
client_hostname  |
client_port  | 50898
backend_start| 2016-10-03 23:24:07.788617-05
backend_xmin |
state| streaming
sent_location| 9/365B2E88
write_location   | 9/365B2E88
flush_location   | 9/365B2E88
replay_location  | 9/365B2C40
sync_priority| 0
sync_state   | async

bd=# select * from pg_replication_slots;

-[ RECORD 1 ]+-
slot_name| replica_calleXX_slot
plugin   |
slot_type| physical
datoid   |
database |
active   | t
active_pid   | 1965
xmin | 8411241
catalog_xmin |
restart_lsn  | 9/3670A150
-[ RECORD 2 ]+-
slot_name| replica_local_slot
plugin   |
slot_type| physical
datoid   |
database |
active   | t
active_pid   | 2054
xmin | 5463120
catalog_xmin |
restart_lsn  | 9/3670A150





2016-10-03 17:38 GMT-05:00 Alvaro Herrera <alvhe...@2ndquadrant.com>:

> Hellmuth Vargas escribió:
>
> > > Ahh, ¿no tendrás un standby con "feedback" activado que tiene una
> > > transacción preparada, o un slot inactivo?  Pega acá
> > > select * from pg_stat_replication
> >
> >
> > bd=# select * from pg_stat_replication
> > bd-# ;
> > -[ RECORD 1 ]+--
> > pid  | 1892
> > usesysid | 10
> > usename  | postgres
> > application_name | walreceiver
> > client_addr  | 192.168.72.XX
> > client_hostname  |
> > client_port  | 46648
> > backend_start| 2016-10-02 11:46:57.003511-05
> > backend_xmin |
> > state| streaming
> > sent_location| 9/11E181C0
> > write_location   | 9/11E181C0
> > flush_location   | 9/11E181C0
> > replay_location  | 9/11E18090
> > sync_priority| 0
> > sync_state   | async
> > -[ RECORD 2 ]+--
> > pid  | 2043
> > usesysid | 10
> > usename  | postgres
> > application_name | walreceiver
> > client_addr  | 10.72.73.YY
> > client_hostname  |
> > client_port  | 55716
> > backend_start| 2016-10-02 11:48:07.38359-05
> > backend_xmin |
> > state| streaming
> > sent_location| 9/11E181C0
> > write_location   | 9/11E181C0
> > flush_location   | 9/11E181C0
> > replay_location  | 9/11E18090
> > sync_priority| 0
> > sync_state   | async
>
> ???
>
> Según controldata que pasaste antes,
>   Latest checkpoint's REDO location:1896/AB72AB00
> No tiene ningún sentido que sent_location acá sea 9/11E181C0. ¿Estamos
> hablando del mismo servidor?
>
> > > select * from pg_replication_slots
> > >
> > > bd=# select * from pg_replication_slots;
> > -[ RECORD 1 ]+-
> > slot_name| replica_calleXX_slot
> > plugin   |
> > slot_type| physical
> > datoid   |
> > database |
> > active   | t
> > active_pid   | 1892
> > xmin | 8355084
> > catalog_xmin |
> > restart_lsn  | 9/11FA3D18
> > -[ RECORD 2 ]+-
> > slot_name| replica_local_slot
> > plugin   |
> > slot_type| physical
> > datoid   |
> > database |
> > active   | t
> > active_pid   | 2043
> > xmin | 5463120
> > catalog_xmin |
> > restart_lsn  | 9/11FA3D18
>
> Ídem; además, el xmin es 8 millones que no está ni cerca del
> Latest checkpoint's NextXID:  0/2021183943
> (dos mil millones) que mostraste en controldata.
>
> Wtf?
>
> --
> Álvaro Herrerahttps://www.2ndQuadrant.com/
> PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
>



-- 
Cordialmente,

Ing. Hellmuth I. Vargas S.
Esp. Telemática y Negocios por Internet
Oracle Database 10g Administrator Certified Associate
EnterpriseDB Certified PostgreSQL 9.3 Associate

Re: [pgsql-es-ayuda] autovacuum excesivo PostgreSQL 9.5

[Hellmuth Vargas]

Hola Alvaro

El 3 de octubre de 2016, 16:39, Alvaro Herrera<alvhe...@2ndquadrant.com>
escribió:

> Hellmuth Vargas escribió:
> > El 3 de octubre de 2016, 16:17, Alvaro Herrera<alvhe...@2ndquadrant.com>
> > escribió:
> >
> > > Hellmuth Vargas escribió:
> > > > Hola Alvaro
> > > >
> > > > Muchas gracias por el tiempo.. respondo entre lineas:
> > >
> > > Pero no respondiste esta parte:
> > >
> > >¿no tendrás alguna transacción preparada abierta?  Mira en
> > >pg_stat_activity y pg_prepared_xacts.
> > >
> > >
> > Perdon Alvaro
>
> Hmm, no hay ninguna "idle in transaction" ni nada que esté ejecutándose
> desde hace más que un rato.  Y no hay ninguna transacción preparada ...
> ¿qué otra cosa puede impedir que vacuum elimine filas?  Supongo que algo
> se me está escapando pero no sé qué.  Por un momento pensé que podría
> haber sido un "backup" abierto, pero eso no debería causar este problema
> que yo recuerde ...
>
> Ahh, ¿no tendrás un standby con "feedback" activado que tiene una
> transacción preparada, o un slot inactivo?  Pega acá
> select * from pg_stat_replication
>


bd=# select * from pg_stat_replication
bd-# ;
-[ RECORD 1 ]+--
pid  | 1892
usesysid | 10
usename  | postgres
application_name | walreceiver
client_addr  | 192.168.72.XX
client_hostname  |
client_port  | 46648
backend_start| 2016-10-02 11:46:57.003511-05
backend_xmin |
state| streaming
sent_location| 9/11E181C0
write_location   | 9/11E181C0
flush_location   | 9/11E181C0
replay_location  | 9/11E18090
sync_priority| 0
sync_state   | async
-[ RECORD 2 ]+--
pid  | 2043
usesysid | 10
usename  | postgres
application_name | walreceiver
client_addr  | 10.72.73.YY
client_hostname  |
client_port  | 55716
backend_start| 2016-10-02 11:48:07.38359-05
backend_xmin |
state| streaming
sent_location| 9/11E181C0
write_location   | 9/11E181C0
flush_location   | 9/11E181C0
replay_location  | 9/11E18090
sync_priority| 0
sync_state   | async



> select * from pg_replication_slots
>
> bd=# select * from pg_replication_slots;
-[ RECORD 1 ]+-
slot_name| replica_calleXX_slot
plugin   |
slot_type| physical
datoid   |
database |
active   | t
active_pid   | 1892
xmin | 8355084
catalog_xmin |
restart_lsn  | 9/11FA3D18
-[ RECORD 2 ]+-
slot_name| replica_local_slot
plugin   |
slot_type| physical
datoid   |
database |
active   | t
active_pid   | 2043
xmin | 5463120
catalog_xmin |
restart_lsn  | 9/11FA3D18





> --
> Álvaro Herrerahttps://www.2ndQuadrant.com/
> PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
>



-- 
Cordialmente,

Ing. Hellmuth I. Vargas S.
Esp. Telemática y Negocios por Internet
Oracle Database 10g Administrator Certified Associate
EnterpriseDB Certified PostgreSQL 9.3 Associate

Re: [pgsql-es-ayuda] autovacuum excesivo PostgreSQL 9.5

[Hellmuth Vargas]

El 3 de octubre de 2016, 16:17, Alvaro Herrera<alvhe...@2ndquadrant.com>
escribió:

> Hellmuth Vargas escribió:
> > Hola Alvaro
> >
> > Muchas gracias por el tiempo.. respondo entre lineas:
>
> Pero no respondiste esta parte:
>
>¿no tendrás alguna transacción preparada abierta?  Mira en
>pg_stat_activity y pg_prepared_xacts.
>
>
Perdon Alvaro

pid backend_start xact_start query_start state_change waiting state
backend_xid backend_xmin query
2329 2016-10-02 11:50:48.211693-05
2016-10-03 16:24:13.078628-05 2016-10-03 16:24:13.080102-05 f idle


1951 2016-10-02 11:47:38.104996-05
2016-10-03 16:24:07.580646-05 2016-10-03 16:24:07.581901-05 f idle


2998 2016-10-02 11:57:18.434209-05
2016-10-03 16:24:11.504117-05 2016-10-03 16:24:11.512482-05 f idle


*1974* *2016-10-03 16:23:59.018115-05* *2016-10-03 16:24:12.994839-05*
*2016-10-03
16:24:12.994839-05* *2016-10-03 16:24:12.99484-05* *f* *active*
*8342722* *autovacuum: VACUUM pg_catalog.pg_attribute*
60412 2016-10-03 15:42:18.497036-05
2016-10-03 16:24:00.295426-05 2016-10-03 16:24:00.295465-05 f idle

COMMIT
62959 2016-10-03 15:58:24.344015-05
2016-10-03 16:12:26.563051-05 2016-10-03 16:12:26.58076-05 f idle

COMMIT
62960 2016-10-03 15:58:24.351477-05
2016-10-03 16:16:24.455809-05 2016-10-03 16:16:24.455825-05 f idle

COMMIT
2244 2016-10-02 11:50:06.527689-05
2016-10-03 16:24:08.550525-05 2016-10-03 16:24:08.550557-05 f idle

COMMIT
2953 2016-10-02 11:56:58.935904-05
2016-10-03 16:24:12.413807-05 2016-10-03 16:24:12.41585-05 f idle


2999 2016-10-02 11:57:18.559647-05
2016-10-03 16:24:11.513935-05 2016-10-03 16:24:11.524073-05 f idle


2290 2016-10-02 11:50:39.419437-05
2016-10-03 16:24:16.042693-05 2016-10-03 16:24:16.057769-05 f idle


*65328* *2016-10-03 16:12:32.051363-05* *2016-10-03
16:13:06.642648-05* *2016-10-03
16:13:06.642648-05* *2016-10-03 16:13:06.642649-05* *f* *active*
*8338139* *autovacuum: VACUUM sac.marcador*
54614 2016-10-03 15:06:17.258045-05
2016-10-03 15:12:29.003785-05 2016-10-03 15:12:29.005669-05 f idle

SELECT column_name FROM information_schema.columns WHERE
table_schema='colpensionessac' AND table_name='tipificacioncorreo' ORDER BY
ordinal_position
51512 2016-10-03 08:06:09.047226-05
2016-10-03 15:59:33.065909-05 2016-10-03 15:59:33.066646-05 f idle


54615 2016-10-03 15:06:17.26081-05
2016-10-03 16:02:23.832531-05 2016-10-03 16:02:23.832585-05 f idle

SET search_path TO "$user", public
51517 2016-10-03 08:06:13.017255-05
2016-10-03 08:07:33.183604-05 2016-10-03 08:07:34.920135-05 f idle


analyze sac.marcador ;
46848 2016-10-03 14:18:36.332516-05
2016-10-03 16:12:26.572828-05 2016-10-03 16:12:26.580269-05 f idle

COMMIT
60004 2016-10-03 15:39:52.918343-05
2016-10-03 16:24:16.06574-05 2016-10-03 16:24:16.065748-05 f idle

COMMIT
46084 2016-10-03 07:32:56.116658-05
2016-10-03 16:12:26.568076-05 2016-10-03 16:12:26.581555-05 f idle

COMMIT
36428 2016-10-03 13:14:09.801684-05
2016-10-03 16:12:19.34997-05 2016-10-03 16:12:19.351039-05 f idle

COMMIT
54857 2016-10-03 15:07:47.494428-05
2016-10-03 15:11:10.2174-05 2016-10-03 15:11:10.217493-05 f idle


28717 2016-10-03 12:26:48.557859-05
2016-10-03 12:26:48.874593-05 2016-10-03 12:26:48.874657-05 f idle

SELECT nspname FROM pg_namespace
59489 2016-10-03 08:55:03.645719-05
2016-10-03 08:57:33.986584-05 2016-10-03 08:57:33.986957-05 f idle

SELECT c.oid, a.attnum, a.attname, c.relname, n.nspname, a.attnotnull OR
(t.typtype = 'd' AND t.typnotnull), pg_catalog.pg_get_expr(d.adbin,
d.adrelid) LIKE '%nextval(%' FROM pg_catalog.pg_class c JOIN
pg_catalog.pg_namespace n ON (c.relnamespace = n.oid) JOIN
pg_catalog.pg_attribute a ON (c.oid = a.attrelid) JOIN pg_catalog.pg_type t
ON (a.atttypid = t.oid) LEFT JOIN pg_catalog.pg_attrdef d ON (d.adrelid =
a.attrelid AND d.adnum = a.attnum) JOIN (SELECT 44940 AS oid , 1 AS attnum
UNION ALL SELECT 44940, 2 UNION ALL SELECT 44940, 3 UNION ALL SELECT 44940,
4 UNION ALL SELECT 44940, 5 UNION ALL SELECT 44940, 6 UNION ALL SELECT
44940, 7 UNION ALL SELECT 44940, 8 UNION ALL SELECT 44940, 9 UNION ALL
SELECT 44940, 10 UNION ALL SELECT 44940, 11 UNION ALL SELECT 44940, 12
UNION ALL SELECT 44940, 13 UNION ALL SELECT 44940, 14 UNION ALL SELECT
44940, 15 UNION ALL SELECT 44940, 16 UNION ALL SELECT 44940, 17 UNION ALL
SELECT 44940, 18 UNION ALL SELECT 44940, 19 UNION ALL SELECT 44940, 20
UNION ALL SELECT 44940, 21 UNION ALL SELECT 44940, 22 UNION ALL SELECT
44940, 23 UNION ALL SELECT 44940, 24 UNION ALL SELECT 44940, 25 UNION ALL
SELECT 44940, 26 UNION ALL SELECT 44940, 27 UNION ALL SELECT 44940, 28
UNION ALL SELECT 44940, 29 UNION ALL SELECT 44940, 30 UNION ALL SELECT
44940, 31 UNION ALL SELECT 44940, 32 UNION ALL SELECT 44940, 33) vals ON
(c.oid = vals.oid AND a.attnum = vals.attnum)
59671 2016-10-03 08:56:18.50717-05
2016-10-03 08:56:18.838372-05 2016-10-03 08:56:18.838396-05 f idle

show search_path
28718 2016-10-03 12:26:48.56114-05
2016-10-03 12:29:44.169251-05 2016-10-03 12:29:44.169288-05 f id

Re: [pgsql-es-ayuda] autovacuum excesivo PostgreSQL 9.5

[Hellmuth Vargas]

Hola Alvaro

Muchas gracias por el tiempo.. respondo entre lineas:


El 3 de octubre de 2016, 16:01, Alvaro Herrera<alvhe...@2ndquadrant.com>
escribió:

> Hellmuth Vargas escribió:
>
> > bd=# select * from  pg_stat_user_tables where relname in ('marcador',
> > 'usuario');
>
> Por alguna razón estas tablas tienen n_dead_tup que no parece decrecer?
> ¿no tendrás alguna transacción preparada abierta?  Mira en
> pg_stat_activity y pg_prepared_xacts.


> Si haces un "vacuum verbose usuario", ¿qué dice?  Me pregunto si
> autovacuum estará arrojando errores antes que termine.  Mira en el log.
>
>
VACUUM FULL analyze verbose sac.marcador;

INFO:  vacuuming "bd.sac.marcador"
INFO:  "marcador": found 0 removable, 2580480 nonremovable row versions in
104585 pages
DETAIL:  1082081 dead row versions cannot be removed yet.
CPU 0.95s/10.97u sec elapsed 26.32 sec.
INFO:  analyzing "sac.marcador"
INFO:  "marcador": scanned 104611 of 104611 pages, containing 1498399 live
rows and 1082098 dead rows; 12 rows in sample, 1498399 estimated total
rows
Query returned successfully with no result in 39.8 secs.


--- log:

_2016-10-03 01:56:26 COTproc:9348 LOG:  automatic vacuum of table
"bd.sac.marcador": index scans: 0
pages: 0 removed, 59776 remain, 0 skipped due to pins
tuples: 0 removed, 2478519 remain, 989963 are dead but not yet
removable
buffer usage: 54441 hits, 70857 misses, 2 dirtied
avg read rate: 4.769 MB/s, avg write rate: 0.000 MB/s
system usage: CPU 0.13s/0.26u sec elapsed 116.06 sec

_2016-10-03 01:58:46 COTproc:9421 LOG:  automatic vacuum of table
"bd.sac.marcador": index scans: 0
pages: 0 removed, 59776 remain, 0 skipped due to pins
tuples: 0 removed, 2478519 remain, 989963 are dead but not yet
removable
buffer usage: 54441 hits, 70857 misses, 2 dirtied
avg read rate: 4.260 MB/s, avg write rate: 0.000 MB/s
system usage: CPU 0.15s/0.24u sec elapsed 129.93 sec

_2016-10-03 02:01:32 COTproc:9581 LOG:  automatic vacuum of table
"bd.sac.marcador": index scans: 0
pages: 0 removed, 59776 remain, 0 skipped due to pins
tuples: 0 removed, 2478519 remain, 989963 are dead but not yet
removable
buffer usage: 54473 hits, 70825 misses, 2 dirtied
avg read rate: 4.524 MB/s, avg write rate: 0.000 MB/s
system usage: CPU 0.13s/0.26u sec elapsed 122.31 sec

--- la tabla usuario:
VACUUM FULL analyze verbose sac.usuario;
INFO:  vacuuming "sac.usuario"
INFO:  "usuario": found 0 removable, 52298 nonremovable row versions in
2201 pages
DETAIL:  52002 dead row versions cannot be removed yet.
CPU 0.01s/0.20u sec elapsed 0.34 sec.
INFO:  analyzing "sac.usuario"
INFO:  "usuario": scanned 2209 of 2209 pages, containing 296 live rows and
52002 dead rows; 296 rows in sample, 296 estimated total rows
Query returned successfully with no result in 2.2 secs.


--- log:

_2016-10-03 01:58:49 COTproc:9421 LOG:  automatic vacuum of table
"bd.sac.usuario": index scans: 0
pages: 0 removed, 1587 remain, 0 skipped due to pins
tuples: 0 removed, 47457 remain, 47161 are dead but not yet
removable
buffer usage: 3450 hits, 1061 misses, 5 dirtied
avg read rate: 2.927 MB/s, avg write rate: 0.014 MB/s
system usage: CPU 0.00s/0.01u sec elapsed 2.83 sec

_2016-10-03 02:00:45 COTproc:9619 LOG:  automatic vacuum of table
"bd.sac.usuario": index scans: 0
pages: 0 removed, 1587 remain, 0 skipped due to pins
tuples: 0 removed, 47457 remain, 47161 are dead but not yet
removable
buffer usage: 3185 hits, 1326 misses, 6 dirtied
avg read rate: 3.009 MB/s, avg write rate: 0.014 MB/s
system usage: CPU 0.00s/0.01u sec elapsed 3.44 sec

_2016-10-03 02:01:36 COTproc:9581 LOG:  automatic vacuum of table
"bd.sac.usuario": index scans: 0
pages: 0 removed, 1587 remain, 0 skipped due to pins
tuples: 0 removed, 47457 remain, 47161 are dead but not yet
removable
buffer usage: 3187 hits, 1324 misses, 6 dirtied
avg read rate: 3.064 MB/s, avg write rate: 0.014 MB/s
system usage: CPU 0.00s/0.00u sec elapsed 3.37 sec


Lo particular es que  esa campaña solo trabaja en horario hábil.. y el log
corresponde a la madrugada cuando no se esta haciendo naday asi se la
pasa tooodo el tiempo


Ademas también se evidencia sobre algunas tablas del sistema

bd=# select * from pg_stat_sys_tables where relname in ('pg_statistic');
-[ RECORD 1 ]---+--
relid   | 2619
schemaname  | pg_catalog
relname | pg_statistic
seq_scan| 38
seq_tup_read| 363762
idx_scan| 4596569
idx_tup_fetch   | 2439173
n_tup_ins   | 329
n_tup_upd   | 78854
n_tu

Re: [pgsql-es-ayuda] autovacuum excesivo PostgreSQL 9.5

[Hellmuth Vargas]

Hola Alvaro

Respondo entre lineas


El 3 de octubre de 2016, 15:15, Alvaro Herrera<alvhe...@2ndquadrant.com>
escribió:

> Hellmuth Vargas escribió:
> > Hola Alvaro, gracias por responder
> >
> > La versión anterior era la postgresql-9.3.12 pero incluso esta base de
> > datos la venia actualizando periódicamente con las diferentes
> publicaciones
> > de la 9.3 y nunca observe el comportamiento que he descrito.
>
> OK.  ¿hay algún patrón visible en las tablas que se les está haciendo
> autovacuum?  Mira el last_autovacuum y last_autoanalyze en
> pg_stat_user_tables y pg_stat_sys_tables.  Si no hay nada extraño (unas
> pocas tablas que se procesen continuamente), activa
> log_autovacuum_min_duration (en 0) para ver qué tablas son las
> afectadas.
>


bd=# select * from  pg_stat_user_tables where relname in ('marcador',
'usuario');
-[ RECORD 1 ]---+--
relid   | 44940
schemaname  | sac
relname | usuario
seq_scan| 15692
seq_tup_read| 5708142
idx_scan| 20595628
idx_tup_fetch   | 19409438
n_tup_ins   | 27
n_tup_upd   | 53326
n_tup_del   | 0
n_tup_hot_upd   | 30722
n_live_tup  | 296
n_dead_tup  | 51691
n_mod_since_analyze | 4530
last_vacuum | 2016-10-03 00:11:41.772669-05
last_autovacuum | 2016-10-03 15:46:05.782991-05
last_analyze| 2016-10-03 00:11:57.540457-05
last_autoanalyze| 2016-09-30 13:56:12.424892-05
vacuum_count| 14
autovacuum_count| *20022*
analyze_count   | 19
autoanalyze_count   | 63
-[ RECORD 2 ]---+--
relid   | 44165
schemaname  | colpensionessac
relname | marcadoroutbound
seq_scan| 871
seq_tup_read| 578174252
idx_scan| 2922480
idx_tup_fetch   | 5844053124
n_tup_ins   | 1114425
n_tup_upd   | 1085804
n_tup_del   | 144
n_tup_hot_upd   | 506464
n_live_tup  | 1497215
n_dead_tup  | 1079276
n_mod_since_analyze | 83183
last_vacuum | 2016-10-03 00:11:34.40105-05
last_autovacuum | 2016-10-03 15:45:34.593168-05
last_analyze| 2016-10-03 08:07:34.91577-05
last_autoanalyze| 2016-09-30 11:08:48.261976-05
vacuum_count| 15
autovacuum_count| *14540*
analyze_count   | 19
autoanalyze_count   | 11




>
> ¿Cuánto es autovacuum_freeze_max_age?  Usa SHOW para mostrarlo.
>

autovacuum;on
autovacuum_analyze_scale_factor;0.05
autovacuum_analyze_threshold;40
autovacuum_freeze_max_age;2
autovacuum_max_workers;5
autovacuum_multixact_freeze_max_age;4
autovacuum_naptime;1min
autovacuum_vacuum_cost_delay;10ms
autovacuum_vacuum_cost_limit;-1
autovacuum_vacuum_scale_factor;0.2
autovacuum_vacuum_threshold;90




>
> > El volcado del control file es:
>
> > Latest checkpoint's NextMultiXactId:  2053905
> > Latest checkpoint's oldestMultiXid:   2052644
> > Latest checkpoint's NextMultiOffset:  3269641
>
> Hmm, esto es extraño creo.  si no leo mal, has usado 1261 multixacts y
> 3269641 miembros, es decir 2592 miembros por multixact?  Eso no tiene
> sentido ... ¿cuántos archivos tienes en pg_multixact/offsets y cuántos
> en pg_multixact/members?   ¿tienes muchas llaves foráneas?
>


[postgres@MBD data]# cd pg_multixact/
[postgres@MBD pg_multixact]# ls
members  offsets
[postgres@MBD pg_multixact]# cd offsets/
[postgres@MBD offsets]# ls -lah
total 96K
drwx-- 2 postgres postgres 4,0K sep 30 01:53 .
drwx-- 4 postgres postgres 4,0K sep 30 01:50 ..
-rwx-- 1 postgres postgres  88K oct  3 15:27 001F
[postgres@MBD offsets]# cd ..
[postgres@MBD pg_multixact]# cd members/
[postgres@MBD members]# ls -lah
total 128K
drwx-- 2 postgres postgres 4,0K sep 30 01:53 .
drwx-- 4 postgres postgres 4,0K sep 30 01:50 ..
-rwx-- 1 postgres postgres 120K oct  3 15:27 003E

Muchas Gracias



>
> --
> Álvaro Herrerahttps://www.2ndQuadrant.com/
> PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
>



-- 
Cordialmente,

Ing. Hellmuth I. Vargas S.
Esp. Telemática y Negocios por Internet

Re: [pgsql-es-ayuda] autovacuum excesivo PostgreSQL 9.5

[Hellmuth Vargas]

Hola Alvaro, gracias por responder

La versión anterior era la postgresql-9.3.12 pero incluso esta base de
datos la venia actualizando periódicamente con las diferentes publicaciones
de la 9.3 y nunca observe el comportamiento que he descrito. El volcado del
control file es:


[postgres@M_BD tmp]# pg_controldata -D ./PostgreSQL/9.5/data/
pg_control version number:942
Catalog version number:   201510051
Database system identifier:   6336011272628208106
Database cluster state:   in production
pg_control last modified: lun 03 oct 2016 14:12:52 COT
Latest checkpoint location:   1896/ACA64958
Prior checkpoint location:1896/9A416FB8
Latest checkpoint's REDO location:1896/AB72AB00
Latest checkpoint's REDO WAL file:0001189600AB
Latest checkpoint's TimeLineID:   1
Latest checkpoint's PrevTimeLineID:   1
Latest checkpoint's full_page_writes: on
Latest checkpoint's NextXID:  0/2021183943
Latest checkpoint's NextOID:  48985
Latest checkpoint's NextMultiXactId:  2053905
Latest checkpoint's NextMultiOffset:  3269641
Latest checkpoint's oldestXID:2014532528
Latest checkpoint's oldestXID's DB:   13236
Latest checkpoint's oldestActiveXID:  2021183943
Latest checkpoint's oldestMultiXid:   2052644
Latest checkpoint's oldestMulti's DB: 13236
Latest checkpoint's oldestCommitTsXid:0
Latest checkpoint's newestCommitTsXid:0
Time of latest checkpoint:lun 03 oct 2016 14:12:05 COT
Fake LSN counter for unlogged rels:   0/1
Minimum recovery ending location: 0/0
Min recovery ending loc's timeline:   0
Backup start location:0/0
Backup end location:  0/0
End-of-backup record required:no
wal_level setting:hot_standby
wal_log_hints setting:off
max_connections setting:  810
max_worker_processes setting: 10
max_prepared_xacts setting:   0
max_locks_per_xact setting:   1024
track_commit_timestamp setting:   off
Maximum data alignment:   8
Database block size:  8192
Blocks per segment of large relation: 131072
WAL block size:   8192
Bytes per WAL segment:16777216
Maximum length of identifiers:64
Maximum columns in an index:  32
Maximum size of a TOAST chunk:1996
Size of a large-object chunk: 2048
Date/time type storage:   64-bit integers
Float4 argument passing:  by value
Float8 argument passing:  by value
Data page checksum version:   0




El 3 de octubre de 2016, 12:26, Alvaro Herrera<alvhe...@2ndquadrant.com>
escribió:

> Hellmuth Vargas escribió:
> > Hola Franciso
> >
> > Si en efecto esta consumiendo mas recursos  y la carga en general de la
> > maquina ha subido en comparación con los valores que mantenía
> (estadísticas
> > SAR) ademas, pues las operaciones que hacia antes son exactamente las
> > mismas que esta haciendo ahora por que no cambio en nada las
> aplicaciones,
> > incluso ya se ha evidenciado que algunas consultas se encolan en esperar
> de
> > la finalización del autovacuum
>
> ¿exactamente qué versión estabas corriendo antes?  Me pregunto si tiene
> que ver con multixact ids.  Pega la salida de pg_controldata.
>
> --
> Álvaro Herrerahttps://www.2ndQuadrant.com/
> PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
>



-- 
Cordialmente,

Ing. Hellmuth I. Vargas S.
Esp. Telemática y Negocios por Internet
Oracle Database 10g Administrator Certified Associate
EnterpriseDB Certified PostgreSQL 9.3 Associate

Re: [pgsql-es-ayuda] autovacuum excesivo PostgreSQL 9.5

[Hellmuth Vargas]

Hola Franciso

Si en efecto esta consumiendo mas recursos  y la carga en general de la
maquina ha subido en comparación con los valores que mantenía (estadísticas
SAR) ademas, pues las operaciones que hacia antes son exactamente las
mismas que esta haciendo ahora por que no cambio en nada las aplicaciones,
incluso ya se ha evidenciado que algunas consultas se encolan en esperar de
la finalización del autovacuum

El 3 de octubre de 2016, 11:27, Francisco Olarte<fola...@peoplecall.com>
escribió:

> Hellmuth:
>
> 2016-10-03 15:21 GMT+02:00 Hellmuth Vargas <hiv...@gmail.com>:
> ...
> > inhabilito, pero ahora prácticamente se mantiene realizaron autovacuum a
> > unas tablas de forma casi permanente, tema que no sucedía antes. Ya les
> ...
>
> Independientemente de que este muchos mas tiempo corriendo el
> autovacuum, ¿ consume mas recursos ( cpu / disco etc ) ? ¿ van las
> aplicaciones mas lentas ? es decir, a ver si es que va mas pausado, o
> que te lo esta mostrando de una forma que aparece mas tiempo corriendo
> que antes.
>
> Francisco Olarte.
>



-- 
Cordialmente,

Ing. Hellmuth I. Vargas S.
Esp. Telemática y Negocios por Internet
Oracle Database 10g Administrator Certified Associate
EnterpriseDB Certified PostgreSQL 9.3 Associate

[pgsql-es-ayuda] autovacuum excesivo PostgreSQL 9.5

[Hellmuth Vargas]

Hola LIsta

El jueves pasado migre una base de datos importante  con gran cantidad de
usuarios y aplicaciones concurrentes  de la versión 9.3 a la 9.5 y me he
encontrado con un aumento significativo (excesivo) de operaciones de
autovacuum que no se evidenciaba en la versión 9.3. Las aplicaciones y los
usuarios son los mismos y los parámetros de configuración se ajustaron de
forma similar (salvo los casos donde cambiaban), pero no solo estos, ademas
 realizamos una instalación nueva  con la versión 9.5 y se evidencia el
mismo comportamiento. Se que el autovacum es importante y por eso nunca lo
inhabilito, pero ahora prácticamente se mantiene realizaron autovacuum a
unas tablas de forma casi permanente, tema que no sucedía antes. Ya les
ajuste el FILL FACTOR de las tablas en cuestión ademas ajuste parámetros
 de autovacuum e incluso autovacuum_work_mem y continua con el mismos
comportamiento.

-- 
Cordialmente,

Ing. Hellmuth I. Vargas S.
Esp. Telemática y Negocios por Internet

Re: [pgsql-es-ayuda] DUDA ACERCA DE TRIGGER

[Hellmuth Vargas]

Hola Lista

yo tengo una duda adicional, como quiere evitar duplicado de
matriculamaestria en educaciondistancia.alumnos  porque no colocar un
UNIQUE sobre el campo y manejar la excepción?

El 30 de septiembre de 2016, 11:43, Emanuel Calvo<3man...@gmail.com>
escribió:

>
>
> Estas generando una llamada infinita al disparador, con eso no hay stack
> que aguante.
>
> Si lo que estás queriendo hacer es manipular los argumentos NEW para
> checkeo (como veo en tu función) u otras cosas,
> no es necesario usar un INSERT, solo retorna NEW.* . Aún así, lo que estás
> queriendo hacer es algo que
> ya se implementa a través de una CONSTRAINT con UNIQUE, a menos que esté
> omitiendo algo.
>
>
>
> On Thu, Sep 29, 2016 at 9:05 PM Maria Antonieta Ramirez <
> marami...@ulsaneza.edu.mx> wrote:
>
>> Buen dia..
>>
>>
>> solicito su ayuda para una duda que tengo ..
>>
>>
>> hice un trigger en el que antes de insertar un registro valide si existe
>> una matricula para lo cual hice lo siguiente.
>>
>>
>>
>>
>> CREATE OR REPLACE FUNCTION educaciondistancia.insert_matricula_maestria()
>>
>>   RETURNS trigger AS
>>
>> $BODY$
>>
>> DECLARE
>>
>> matricula record ;
>>
>> BEGIN
>>
>>
>>  SELECT * INTO matricula FROM educaciondistancia.alumnos WHERE
>> matriculamaestria = NEW.matriculamaestria;
>>
>>IF NOT FOUND THEN
>>
>>INSERT INTO educaciondistancia.alumnos (
>>
>>   nombre , apellidopaterno , apellidomaterno, sexo , fechanac
>> , lugarnac , nacionalidad , calle, numext, numint, colonia ,ciudad,
>> municipio,estado,pais,cp, telefono,
>>
>>   telcelular,ocupacion,estatus, email,nickname,foto,
>> fecharegistro,matriculamaestria,aspirantemaestria,grupo, folioaspirante)
>>
>>VALUES (
>>
>>   NEW.nombre , NEW.apellidopaterno , NEW.apellidomaterno,
>> NEW.sexo , NEW.fechanac , NEW.lugarnac , NEW.nacionalidad , NEW.calle,
>> NEW.numext, NEW.numint, NEW.colonia , NEW.ciudad, NEW.municipio,
>> NEW.estado, NEW.pais, NEW.cp, NEW.telefono, NEW.
>>
>>   telcelular, NEW.ocupacion, NEW.estatus, NEW.email,
>> NEW.nickname, NEW.foto, NEW.fecharegistro, NEW.matriculamaestria,
>> NEW.aspirantemaestria, NEW.grupo, NEW.folioaspirante);
>>
>>
>>END IF;
>>
>> RETURN NEW;
>>
>> END;
>>
>> $BODY$
>>
>>   LANGUAGE plpgsql VOLATILE
>>
>>   COST 100;
>>
>> ALTER FUNCTION educaciondistancia.insert_matricula_maestria()
>>
>>   OWNER TO postgres;
>>
>>
>>
>>
>> CREATE TRIGGER tr_insert_matricula_maestria
>>
>>   BEFORE INSERT
>>
>>   ON educaciondistancia.alumnos
>>
>>   FOR EACH ROW
>>
>>   EXECUTE PROCEDURE educaciondistancia.insert_matricula_maestria();
>>
>>
>>
>>
>>
>>
>>
>> **
>>
>>
>> cuando hice pruebas por medio de pgadmin insertando mi registro , no me
>> mando ningun problema. pero el dia de hoy lo probe de nuevo y en uno de los
>> intentos de las pruebas me mando el siguiente mensaje:
>>
>>
>>
>>
>>
>>
>> me podrian apoyar en saber a que se refiere.
>>
>>
>> Por su atencion muchas gracias!!!
>>
>>
>>
>>
>>
>>


-- 
Cordialmente,

Ing. Hellmuth I. Vargas S.
Esp. Telemática y Negocios por Internet
Oracle Database 10g Administrator Certified Associate
EnterpriseDB Certified PostgreSQL 9.3 Associate

[pgsql-es-ayuda] Re: [pgsql-es-ayuda] creación automática de secuencias impares

[Hellmuth Vargas]

 no me acordaba de los event trigger o mas bien de que habían mejorado
en la 9.5... Gracias Alvaro!!

El 22 de septiembre de 2016, 14:26, Alvaro Herrera<alvhe...@2ndquadrant.com>
escribió:

> Hellmuth Vargas escribió:
>
> > Quisiera saber como podria configurar a justar en PostgreSQL para que
> todas
> > las secuencias que se definan en una base de datos siempre se creen
> impares
> > SIN IMPORTAR como se envíe la sentencia DDL de la misma. Hay varios
> > usuarios accediendo y creado objectos por lo tanto debe ser algo
> > automático.
>
> Si estás en 9.5 podrías poner un event trigger que modifique la
> secuencia después de creada, examinando la función
> pg_event_trigger_ddl_commands() en el evento ddl_command_end (by yours
> truly), pero creo que tendría que escribir algo de código en C.  O
> quizás con la información provista se pueda hacer en plpgsql.  Mira la
> documentación
> https://www.postgresql.org/docs/9.5/static/functions-event-triggers.html
>
> --
> Álvaro Herrerahttps://www.2ndQuadrant.com/
> PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
>



-- 
Cordialmente,

Ing. Hellmuth I. Vargas S.
Esp. Telemática y Negocios por Internet
Oracle Database 10g Administrator Certified Associate
EnterpriseDB Certified PostgreSQL 9.3 Associate

[pgsql-es-ayuda] creación automática de secuencias impares

[Hellmuth Vargas]

Hola Lista

Quisiera saber como podria configurar a justar en PostgreSQL para que todas
las secuencias que se definan en una base de datos siempre se creen impares
SIN IMPORTAR como se envíe la sentencia DDL de la misma. Hay varios
usuarios accediendo y creado objectos por lo tanto debe ser algo
automático. De antemano gracias!!!

Una aclaración: necesito solo que las  secuencias se generen impares, las
claves primarias si pueden tener valores pares o impares.

-- 
Cordialmente,

Ing. Hellmuth I. Vargas S.

[pgsql-es-ayuda] Re: [pgsql-es-ayuda] Re: [pgsql-es-ayuda] Re: [MASSMAIL] [pgsql-es-ayuda] Diseño de Tabla para Empleados, Clientes y Proveedores

[Hellmuth Vargas]

Perdón  es Alberto


El 14 de septiembre de 2016, 16:10, Hellmuth Vargas<hiv...@gmail.com>
escribió:

> Hola Alverto
>
> El tema es que la tabla persona  debe contener la informacion de todos los
> actores que se involucran en su sistema y ya en otra tabla (factura,
> cliente ,etc) es donde se clasifica y/o se le atribuye un rol la persona
>  para un evento dado (cliente, provedor, contacto, etc)
>
> Por ejemplo  es un sistema de facturación, una persona puede ser
> proveedor, y para otra factura un cliente y para una tercera un contacto y
> sin embargo sigue siendo la misma persona.
>
>
>
>
>
>
> El 14 de septiembre de 2016, 16:03, Gilberto Castillo<gilberto.castillo@
> etecsa.cu> escribió:
>
>>
>> > Alvaro gracias por responder.
>> >
>> > En la tabla Persona, relacione con la tabla Tipo_Persona para saber que
>> > tipo es, muy aparte por cada tipo tendre una tabla sea Cliente,
>> Empleado,
>> > Proveedor, etc, de ser necesario.
>>
>> Alberto, no se si lees bien lo que Alvaro te plantea, Se supone que si la
>> persona tiene un id_p en la tabla clientes es porque es un cliente, y así
>> sucesivamente, o sea, la tabla tipo_persona me sobra en ese modelo.
>>
>>
>> > En Persona_Relacion, solo tendre la relacion entre persona para los
>> > contactos.
>> >
>> > Bueno eso es lo que se me ocurre.
>> >
>> > Saludos.
>> >
>> > El mié., 14 sept. 2016 a las 15:37, Alvaro Herrera (<
>> > alvhe...@2ndquadrant.com>) escribió:
>> >
>> >> Alberto Cuevas escribió:
>> >> > Gracias por responder, bueno tengo una 1ra versión del modelo que
>> >> deseo
>> >> > implementar:
>> >> >
>> >> > *Modelo 1:*
>> >> >
>> >> > Crear las tablas:
>> >>
>> >> no entiendo por qué tus personas tienen un "tipo" (en ambos modelos
>> >> propuestos).  Un registro de la tabla personas debería representar a
>> una
>> >> persona, y luego tienes una table de clientes que pueden llevar un tipo
>> >> y una FK a la tabla personas.  ¿no?
>> >>
>> >> --
>> >> Álvaro Herrerahttps://www.2ndQuadrant.com/
>> >> PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
>> >>
>> >
>>
>>
>> --
>> Saludos,
>> Gilberto Castillo
>> ETECSA, La Habana, Cuba
>>
>>
>
>
> --
> Cordialmente,
>
> Ing. Hellmuth I. Vargas S.
> Esp. Telemática y Negocios por Internet
> Oracle Database 10g Administrator Certified Associate
> EnterpriseDB Certified PostgreSQL 9.3 Associate
>
>


-- 
Cordialmente,

Ing. Hellmuth I. Vargas S.
Esp. Telemática y Negocios por Internet
Oracle Database 10g Administrator Certified Associate
EnterpriseDB Certified PostgreSQL 9.3 Associate

[pgsql-es-ayuda] Re: [pgsql-es-ayuda] Re: [pgsql-es-ayuda] Re: [MASSMAIL] [pgsql-es-ayuda] Diseño de Tabla para Empleados, Clientes y Proveedores

[Hellmuth Vargas]

Hola Alverto

El tema es que la tabla persona  debe contener la informacion de todos los
actores que se involucran en su sistema y ya en otra tabla (factura,
cliente ,etc) es donde se clasifica y/o se le atribuye un rol la persona
 para un evento dado (cliente, provedor, contacto, etc)

Por ejemplo  es un sistema de facturación, una persona puede ser proveedor,
y para otra factura un cliente y para una tercera un contacto y sin embargo
sigue siendo la misma persona.






El 14 de septiembre de 2016, 16:03, Gilberto Castillo<
gilberto.casti...@etecsa.cu> escribió:

>
> > Alvaro gracias por responder.
> >
> > En la tabla Persona, relacione con la tabla Tipo_Persona para saber que
> > tipo es, muy aparte por cada tipo tendre una tabla sea Cliente, Empleado,
> > Proveedor, etc, de ser necesario.
>
> Alberto, no se si lees bien lo que Alvaro te plantea, Se supone que si la
> persona tiene un id_p en la tabla clientes es porque es un cliente, y así
> sucesivamente, o sea, la tabla tipo_persona me sobra en ese modelo.
>
>
> > En Persona_Relacion, solo tendre la relacion entre persona para los
> > contactos.
> >
> > Bueno eso es lo que se me ocurre.
> >
> > Saludos.
> >
> > El mié., 14 sept. 2016 a las 15:37, Alvaro Herrera (<
> > alvhe...@2ndquadrant.com>) escribió:
> >
> >> Alberto Cuevas escribió:
> >> > Gracias por responder, bueno tengo una 1ra versión del modelo que
> >> deseo
> >> > implementar:
> >> >
> >> > *Modelo 1:*
> >> >
> >> > Crear las tablas:
> >>
> >> no entiendo por qué tus personas tienen un "tipo" (en ambos modelos
> >> propuestos).  Un registro de la tabla personas debería representar a una
> >> persona, y luego tienes una table de clientes que pueden llevar un tipo
> >> y una FK a la tabla personas.  ¿no?
> >>
> >> --
> >> Álvaro Herrerahttps://www.2ndQuadrant.com/
> >> PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
> >>
> >
>
>
> --
> Saludos,
> Gilberto Castillo
> ETECSA, La Habana, Cuba
>
>


-- 
Cordialmente,

Ing. Hellmuth I. Vargas S.
Esp. Telemática y Negocios por Internet
Oracle Database 10g Administrator Certified Associate
EnterpriseDB Certified PostgreSQL 9.3 Associate

[pgsql-es-ayuda] Re: [pgsql-es-ayuda] Re: [MASSMAIL] [pgsql-es-ayuda] Diseño de Tabla para Empleados, Clientes y Proveedores

[Hellmuth Vargas]

Hola Lista

Estoy de acuerdo con Gilberto: lo mejor es mantener una tabla PERSONA y mas
bien en cada operación se define el ROL que cumple cada persona en la
misma: es cliente, proveedor o contacto

El 13 de septiembre de 2016, 16:38, Gilberto Castillo<
gilberto.casti...@etecsa.cu> escribió:

>
> > Hay casos en que un Contacto puede ser de N Clientes y tambien puede ser
> > Cliente en ese caso trabajarlo en una sola tabla, no lo veo como.
>
> No, no no he dicho que quites tus tablas de clientes etc. solo que todas
> toman  información de personas, solo eso.
>
>
> >
> > Alguna idea.
> >
> > Saludos.
> >
> > El mar., 13 sept. 2016 a las 15:35, Gilberto Castillo (<
> > gilberto.casti...@etecsa.cu>) escribió:
> >
> >>
> >> > Gracias por responder Gilberto.
> >> >
> >> > Al manejar todo en una sola tabla Persona (Empleados, Clientes y
> >> > Proveedores) me queda claro, pero mi duda es con los Contactos de
> >> Clientes
> >> > que también pueden ser Clientes. Se me ocurre tener una tabla
> >> > PersonaContacto con:
> >> >
> >> > ID_TBL_CONTACTO PK de tabla PersonaContacto
> >> > PERSONA_ID  = ID de tabla Persona CLIENTE
> >> > CONTACTO_ID = ID de tabla Persona CONTACTO
> >>
> >> Al final todos son personas, así con un codificador de su estados ya
> >> tienes.
> >>
> >>
> >> > Pero no tendria relación, alguna idea.
> >> >
> >> > Saludos.
> >> >
> >> >
> >> > El mar., 13 sept. 2016 a las 15:10, Gilberto Castillo (<
> >> > gilberto.casti...@etecsa.cu>) escribió:
> >> >
> >> >>
> >> >> > Hola a todos, quisiera contar con su apoyo, con respecto a lo
> >> >> siguiente:
> >> >> >
> >> >> > Siempre he trabajado el registro de Empleados, Clientes y
> >> Proveedores
> >> >> por
> >> >> > separado, Contactos de Clientes y Contactos de Proveedores tambien
> >> por
> >> >> > separado, pero en una empresa en la cual voy a implementar un
> >> software
> >> >> de
> >> >> > ventas, tienen una particularidad, pues una persona puede ser
> >> >> Empleado,
> >> >> > Cliente y Proveedor a la vez.
> >> >> >
> >> >> > He pensado tener en una sola tabla el registro de Empleados,
> >> Clientes
> >> >> y
> >> >> > Proveedores y tener tablas independientes por cada uno si se
> >> requiere.
> >> >> >
> >> >> > De igual manera una sola tabla para la direccion de Empleados,
> >> >> Clientes y
> >> >> > Proveedores.
> >> >> >
> >> >> > Pero hay un caso mas, un Contacto de un Cliente puede ser tambien
> >> un
> >> >> > Cliente o Proveedor.
> >> >> >
> >> >> > Alguna idea de algún compañero que haya tenido un caso similar, que
> >> >> pueda
> >> >> > ayudarme por favor.
> >> >> >
> >> >>
> >> >> Bueno te creas una tabla personas, de hechos los sistemas nuestro
> >> parte
> >> >> siempre de esa tabla, pos la persona es la célula más atómica por lo
> >> >> general.
> >> >>
> >> >>
> >> >> --
> >> >> Saludos,
> >> >> Gilberto Castillo
> >> >> ETECSA, La Habana, Cuba
> >> >>
> >> >>
> >> >
> >>
> >>
> >> --
> >> Saludos,
> >> Gilberto Castillo
> >> ETECSA, La Habana, Cuba
> >>
> >>
> >
>
>
> --
> 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
>



-- 
Cordialmente,

Ing. Hellmuth I. Vargas S.
Esp. Telemática y Negocios por Internet
Oracle Database 10g Administrator Certified Associate
EnterpriseDB Certified PostgreSQL 9.3 Associate

[pgsql-es-ayuda] actualizacion de pg9.4 a 9.5 con replicas con replication_slot

[Hellmuth Vargas]

Hola Lista

acabe de  actualizar un cluster PostgreSQL 9.4 con 2 replicas a la versión
9.5 siguiendo el procedimiento  descrito aquí (
https://www.postgresql.org/docs/9.5/static/pgupgrade.html) para la
actualización de las replicas sin necesidad de reconstruirlas
completamente. Todo funciona perfectamente salvo que todos los
replication_slot´s para  Streaming Replication definidos en la master se
habían borrado. Por lo tanto cuando subían las replicas  presentaban error.
Se subsano sencillamente  creado nuevamente los replication_slot
correspondientes en la master... para que lo tengan en cuenta.

-- 
Cordialmente,

Ing. Hellmuth I. Vargas S.

Re: [pgsql-es-ayuda] Tipo de dato para no tener problemas con el redondeo

[Hellmuth Vargas]

como lo expuso Jaime ;-)

https://www.postgresql.org/docs/9.5/static/datatype-numeric.html

NameStorage SizeDescriptionRange
smallint 2 bytes small-range integer -32768 to +32767
integer 4 bytes typical choice for integer -2147483648 to +2147483647
bigint 8 bytes large-range integer -9223372036854775808 to
+9223372036854775807
decimal variable user-specified precision, exact up to 131072 digits before
the decimal point; up to 16383 digits after the decimal point
numeric variable user-specified precision, exact up to 131072 digits before
the decimal point; up to 16383 digits after the decimal point
real 4 bytes variable-precision, inexact 6 decimal digits precision
double precision 8 bytes variable-precision, inexact 15 decimal digits
precision
smallserial 2 bytes small autoincrementing integer 1 to 32767
serial 4 bytes autoincrementing integer 1 to 2147483647
bigserial 8 bytes large autoincrementing integer 1 to 9223372036854775807

El 10 de agosto de 2016, 16:21, Jaime Casanova<
jaime.casan...@2ndquadrant.com> escribió:

> 2016-08-10 16:17 GMT-05:00 jvenegasperu . :
> >
> > Que tipo de dato seria el mas adecuado para no tener problemas de
> redondeo.
> >
> > Estoy viendo si usar el tipo de dato real Real o Numeric que me muestra
>
> numeric
>
> --
> Jaime Casanova  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
>



-- 
Cordialmente,

Ing. Hellmuth I. Vargas S.
Esp. Telemática y Negocios por Internet
Oracle Database 10g Administrator Certified Associate
EnterpriseDB Certified PostgreSQL 9.3 Associate

Re: [pgsql-es-ayuda] RECOVERYXLOG

[Hellmuth Vargas]

Hola Lista


El 3 de agosto de 2016, 11:40, Kernel escribió:

>
> Hola ,
> siguedo esta guia (http://www.postgresql.org.es/node/483?page=1) nunca he
> tenido problemas para montar la replicacion, hasta ahora
>
>
> http://www.postgresql.org.es/node/483?page=1
>
>
> He actualizado una maquina a esclava a la 9.2.17 y no consigo poner en
> marcha la repliacacion, me da este error al arrancar la maquina esclava
>
>
> FATAL:  no se pudo abrir el archivo «pg_xlog/RECOVERYXLOG»: Permiso
> denegado
>

Según el mensaje de error, se trata de permisos sobre el archivo y/o
carpeta, verifique que el dueño de la misma sea el usuario dueño del
cluster y qeu tenga los permisos apropiados:

por ejemplo, para el caso que PostgreSQL se ejecute con el usuario postgres:


sudo chown postgres  pg_xlog/ -R
sudo chmod 700 pg_xlog/ -R



>
> He le ido algo de un bug, pero me fio muy poco de mi ingles
>
> ¿sabeis algo de este tema?
>
> Un saludo
>
>
>
> -
> 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
>



-- 
Cordialmente,

Ing. Hellmuth I. Vargas S.
Esp. Telemática y Negocios por Internet
Oracle Database 10g Administrator Certified Associate
EnterpriseDB Certified PostgreSQL 9.3 Associate

Re: [pgsql-es-ayuda] Estadisticas de base de datos y archivo de configuracion

[Hellmuth Vargas]

Hola Lista

El 27 de julio de 2016, 10:35, Alberto Cardenas Cardenas<
alberto.cardenas.c...@gmail.com> escribió:

> Hola Lista, una consulta, necesito generar estadisticas de uso de la base
> de datos, entiendase por uso operaciones de escritura, como Insert, Update,
> Delete. Mi pregunta es, existe alguna vista donde esta información se
> guarde, no necesito el tamaño de la base de datos , indices o tablas, sino
> que el uso en las operaciones de escrituras. algo asi como cantidad de
> bytes escritos,
> aparte de la vista vista pg_stat_all_tables, existe otra que pueda utilizar
> necesito esto para un analisis de disco duro que estoy haciendo.
>
>
>
> La segunda consulta es aparte del archivo postgresql.con, donde esta la
> configuracion de la base de datos, existe alguna vista que contenga esta
> información, lo que necesito es poder obtener los parametros por defecto y
> compararlos con los parametros actuales de la base de datos
>
>
SELECT  * FROM  pg_settings;



> de antemano gracias por su ayuda
>
> Alberto
>



-- 
Cordialmente,

Ing. Hellmuth I. Vargas S.
Esp. Telemática y Negocios por Internet
Oracle Database 10g Administrator Certified Associate
EnterpriseDB Certified PostgreSQL 9.3 Associate

Re: [pgsql-es-ayuda] Usando WAL en memoria junto con streaming replication

[Hellmuth Vargas]

Hola Lista


Pero tengo entendido que ejecutar un pg_resetxlog es el ultimo recurso y
 una vez suba la instancia hay realizar un dump/initdb/restore

https://www.postgresql.org/docs/9.4/static/app-pgresetxlog.html

"After running this command, it should be possible to start the server, but
bear in mind that the database might contain inconsistent data due to
partially-committed transactions. You should immediately dump your data, run
initdb, and reload. After reload, check for inconsistencies and repair as
needed."





El 12 de julio de 2016, 07:27, Hellmuth Vargas<hiv...@gmail.com> escribió:

> Hola Lista
>
>
> Pero tengo e tendido
>
>
> After running this command, it should be possible to start the server, but
> bear in mind that the database might contain inconsistent data due to
> partially-committed transactions. You should immediately dump your data, run
> initdb, and reload. After reload, check for inconsistencies and repair as
> needed.
>
> El 11 de julio de 2016, 21:43, Alvaro Herrera<alvhe...@2ndquadrant.com>
> escribió:
>
>> Jaime Casanova escribió:
>> > 2016-07-08 5:04 GMT-05:00 Francisco Olarte <fola...@peoplecall.com>:
>> > > Eduardo:
>> > >
>> > > 2016-07-07 19:40 GMT+02:00 Eduardo Morras <emorr...@yahoo.es>:
>> > > ...
>> > >>> Es mas, haz una prueba pero me da que el maestro, salvo que hagas
>> > >>> algun truco para guardar el xlog, se pudriria no solo cuando se
>> > >>> ahostie, sino tambien cuando pares la maquina ( la prueba es facil,
>> > >>> coge un cluster, paralo, borra el directorio de xlog, arranca a ver
>> > >>> que pasa ), en cuyo caso vas a tener mas movidas aun con los
>> upgrades.
>> > >> Ahi depende de como pares la maquina. Siempre parar primero Postgres
>> > >> (pg_ctl stop -m smart) y despues hacer el shutdown. Nunca confio en
>> que
>> > >> llamar a shutdown directamente pueda parar correctamente postgres o
>> > >> cualquier otro demonio mio, tiene la mala costumbre de matar todo
>> > >> pasado un timeout y dejar las cosas a medio hacer.
>> > >
>> > > No, no es eso lo que digo. Lo que digo es que en condiciones normales
>> > > si tu haces un reboot, y tienes la maquina bien configurada, el
>> > > postgres tiene el xlog ahi cuando rearranca, que no se lo que se queda
>> > > dentro. La cosa es si puede hacer un pgctl stop smart, borrar el
>> > > directorio de xlog, pgctl start y sigue funcionando.
>> >
>> > no, no puedes.
>> > al arrancar postgres necesita ver no solo el directorio pg_xlog,
>> > tambien necesita ver segmentos del WAL (lo que va dentro del
>> > directorio) de al menos 2 chekpoints para atras...
>>
>> Sólo un checkpoint para atrás (el anterior se usa sólo si por alguna
>> razón no puede leer el último) ... y en un "smart shutdown" (y también
>> en un fast shutdown) el sistema escribe un checkpoint de apagado al
>> terminar, así que en realidad no necesitaría leer nada.  Pero el sistema
>> no tiene cómo saber que no hay nada después del checkpoint de apagado,
>> sin leer el último segmento de WAL.
>>
>> Supongo que podría hacer un pg_resetxlog antes de partir.
>>
>> --
>> Á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
>>
>
>
>
> --
> Cordialmente,
>
> Ing. Hellmuth I. Vargas S.
> Esp. Telemática y Negocios por Internet
> Oracle Database 10g Administrator Certified Associate
> EnterpriseDB Certified PostgreSQL 9.3 Associate
>
>


-- 
Cordialmente,

Ing. Hellmuth I. Vargas S.
Esp. Telemática y Negocios por Internet
Oracle Database 10g Administrator Certified Associate
EnterpriseDB Certified PostgreSQL 9.3 Associate

Re: [pgsql-es-ayuda] Usando WAL en memoria junto con streaming replication

[Hellmuth Vargas]

Hola Lista


Pero tengo e tendido


After running this command, it should be possible to start the server, but
bear in mind that the database might contain inconsistent data due to
partially-committed transactions. You should immediately dump your data, run
initdb, and reload. After reload, check for inconsistencies and repair as
needed.

El 11 de julio de 2016, 21:43, Alvaro Herrera
escribió:

> Jaime Casanova escribió:
> > 2016-07-08 5:04 GMT-05:00 Francisco Olarte :
> > > Eduardo:
> > >
> > > 2016-07-07 19:40 GMT+02:00 Eduardo Morras :
> > > ...
> > >>> Es mas, haz una prueba pero me da que el maestro, salvo que hagas
> > >>> algun truco para guardar el xlog, se pudriria no solo cuando se
> > >>> ahostie, sino tambien cuando pares la maquina ( la prueba es facil,
> > >>> coge un cluster, paralo, borra el directorio de xlog, arranca a ver
> > >>> que pasa ), en cuyo caso vas a tener mas movidas aun con los
> upgrades.
> > >> Ahi depende de como pares la maquina. Siempre parar primero Postgres
> > >> (pg_ctl stop -m smart) y despues hacer el shutdown. Nunca confio en
> que
> > >> llamar a shutdown directamente pueda parar correctamente postgres o
> > >> cualquier otro demonio mio, tiene la mala costumbre de matar todo
> > >> pasado un timeout y dejar las cosas a medio hacer.
> > >
> > > No, no es eso lo que digo. Lo que digo es que en condiciones normales
> > > si tu haces un reboot, y tienes la maquina bien configurada, el
> > > postgres tiene el xlog ahi cuando rearranca, que no se lo que se queda
> > > dentro. La cosa es si puede hacer un pgctl stop smart, borrar el
> > > directorio de xlog, pgctl start y sigue funcionando.
> >
> > no, no puedes.
> > al arrancar postgres necesita ver no solo el directorio pg_xlog,
> > tambien necesita ver segmentos del WAL (lo que va dentro del
> > directorio) de al menos 2 chekpoints para atras...
>
> Sólo un checkpoint para atrás (el anterior se usa sólo si por alguna
> razón no puede leer el último) ... y en un "smart shutdown" (y también
> en un fast shutdown) el sistema escribe un checkpoint de apagado al
> terminar, así que en realidad no necesitaría leer nada.  Pero el sistema
> no tiene cómo saber que no hay nada después del checkpoint de apagado,
> sin leer el último segmento de WAL.
>
> Supongo que podría hacer un pg_resetxlog antes de partir.
>
> --
> Á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
>



-- 
Cordialmente,

Ing. Hellmuth I. Vargas S.
Esp. Telemática y Negocios por Internet
Oracle Database 10g Administrator Certified Associate
EnterpriseDB Certified PostgreSQL 9.3 Associate

Re: [pgsql-es-ayuda] LIKE a campo integer

[Hellmuth Vargas]

Hola Herman



El filtro no debería aplicarse sobre la llave foranea ID_TIP_REG, la
consulta hipotética seria algo así:

SELECT campos
FROM tabla1 AS a
JOIN PRD_REG AS b ON a.ID_TIP_REG=b.ID_TIP_REG
WHERE b.*NOM_TIP_REG like param*:

donde *param* puede ser cualquier de los valores del dominio
(DETALLADO,MARCADO...) o % para el caso de todos. Por lo tanto
la función que implemento no debe recibir el ID_TIP_REG sino el valor
de NOM_TIP_REG ya que, según menciono, igual hace el JOIN con la otra
tabla, la recomendación es que la llave foranea ID_TIP_REG en tabla1
debería estar indexada







El 21 de junio de 2016, 19:47, Herman Estaban
escribió:

> Gracias por las respuestas.
>
> Voy a explicar mejor lo que requiero.
>
> 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;
>
> Pero que tan eficiente es usar LIKE con campos INTEGER, es una practica
> recomendable?
>
> Debo trabajar con campos CHAR para usar el LIKE quizas por rapides?
>
> Saludos.
>
>
>
>
>


-- 
Cordialmente,

Ing. Hellmuth I. Vargas S.
Esp. Telemática y Negocios por Internet
Oracle Database 10g Administrator Certified Associate
EnterpriseDB Certified PostgreSQL 9.3 Associate

Re: [pgsql-es-ayuda] LIKE a campo integer

[Hellmuth Vargas]

Hola Herman

En ese caso, si tiene bastantes registros, la distribución es mas o menos
heterogénea y la consulta se trata de prefijo (empieza por) podría probar:

1.Crear indice sobre la versión texto de la columna entera, ejemplo:

CREATE INDEX idx_indice_patron ON tabla (CAST(ID_TIP_REG  AS TEXT)
text_pattern_ops);


2. verificar el funcionamiento:

WHERE CAST(ID_TIP_REG  AS TEXT) LIKE param;




El 21 de junio de 2016, 16:36, Herman Estaban<hermanesta...@gmail.com>
escribió:

> Hellmuth gracias por la respuesta.
>
> Necesito el LIKE para devolver todo los codigos y tambien elegir un codigo
> especifico.
>
> WHERE CAST(ID_TIP_REG AS CHAR) LIKE param;
>
> param : Que puede ser '%' todos o cualquiera de estos codigos 1, 2, 3, 4,
> 5, 6, 7, 8, 9, 10, 11, 12, 13, 99.
>
> Como ya habia mencionado los campos primary key y foreign key son de tipo
> de datos INTEGER o BIGINT, tengo tambien campos indicadores  que son de
> tipo CHAR(1) 'A' = ANULADO, 'V' = VIGENTE, '0'= INACTIVO, '1' = INACTIVO
> por dar unos ejemplos, deberia trabajar estos con tipo de dato INTEGER,
> seria mas eficiente, ya que trabajo los campos primary key y foreign key
> porque INTEGER  es mas rapido en las busquedas que usando CHAR.
>
> Saludos.
>
> El mar., 21 jun. 2016 a las 16:16, Hellmuth Vargas (<hiv...@gmail.com>)
> escribió:
>
>> Hola Herman
>>
>>
>> Pensaría que tiene algo  como:
>>
>> dominio de ID_TIP_REG:
>> de 100 a 199 -> categoria1
>> de 200 a 299 -> categoria2
>> de 300 a 399 -> categoria3
>> 
>>
>>
>> Si es así no debería utilizar LIKE sin mas bien un BETWEEN
>>
>>
>> WHERE ID_TIP_REG BETWEEN  AND > categoria>
>>
>>
>>
>>
>> El 21 de junio de 2016, 16:01, Herman Estaban<hermanesta...@gmail.com>
>> escribió:
>>
>>> Buenas tardes, todos los campos primary key y foreign key de mis tablas
>>> son de tipo de datos INTEGER y BIGINT.
>>>
>>> Y tengo la necesidad de hacer un LIKE a un campo de tipo INTEGER en un
>>> SELECT.
>>>
>>> Que tan eficiente es hacer esto:
>>>
>>> WHERE CAST(ID_TIP_REG AS CHAR) LIKE '1%'
>>>
>>> LIKE es mas rapido con CHAR, VARCHAR que con INTEGER?
>>>
>>> Espero sus comentarios.
>>>
>>> Saludos.
>>>
>>
>>
>>
>> --
>> Cordialmente,
>>
>> Ing. Hellmuth I. Vargas S.
>> Esp. Telemática y Negocios por Internet
>> Oracle Database 10g Administrator Certified Associate
>> EnterpriseDB Certified PostgreSQL 9.3 Associate
>>
>>


-- 
Cordialmente,

Ing. Hellmuth I. Vargas S.
Esp. Telemática y Negocios por Internet
Oracle Database 10g Administrator Certified Associate
EnterpriseDB Certified PostgreSQL 9.3 Associate

Re: [pgsql-es-ayuda] LIKE a campo integer

[Hellmuth Vargas]

Hola Herman


Pensaría que tiene algo  como:

dominio de ID_TIP_REG:
de 100 a 199 -> categoria1
de 200 a 299 -> categoria2
de 300 a 399 -> categoria3



Si es así no debería utilizar LIKE sin mas bien un BETWEEN


WHERE ID_TIP_REG BETWEEN  AND 




El 21 de junio de 2016, 16:01, Herman Estaban
escribió:

> Buenas tardes, todos los campos primary key y foreign key de mis tablas
> son de tipo de datos INTEGER y BIGINT.
>
> Y tengo la necesidad de hacer un LIKE a un campo de tipo INTEGER en un
> SELECT.
>
> Que tan eficiente es hacer esto:
>
> WHERE CAST(ID_TIP_REG AS CHAR) LIKE '1%'
>
> LIKE es mas rapido con CHAR, VARCHAR que con INTEGER?
>
> Espero sus comentarios.
>
> Saludos.
>



-- 
Cordialmente,

Ing. Hellmuth I. Vargas S.
Esp. Telemática y Negocios por Internet
Oracle Database 10g Administrator Certified Associate
EnterpriseDB Certified PostgreSQL 9.3 Associate

[pgsql-es-ayuda] Re: [pgsql-es-ayuda] obtener el tamaño del resultado en una consulta en el log de postgres

[Hellmuth Vargas]

Hola Alvaro y Anthony

Pues realmente necesito una estimación únicamente por lo tanto voy a
implementarlo y les cuento.. muchas gracias por sus respuestas!!!

El 16 de junio de 2016, 14:29, Alvaro Herrera
escribió:

> Anthony Sotolongo escribió:
> > Hola Hellmuth, no se si hay algún parámetro en el archivo de
> configuración
> > para eso, al menos no lo veo, pero puede que lo haya o la combinación de
> > algunos. También creo que puedes lograr un "aproximado" del resultado del
> > EXPLAIN  según entiendo de  la documentación
> > (https://www.postgresql.org/docs/current/static/using-explain.html), si
> > tienes las estadísticas actualizadas mejor:
>
> Juntar eso con auto_explain da una estimación de la respuesta que
> buscas.  Pero ojo, es sólo la estimación del optimizador, no son los
> valores reales.  Para saber los valores exactos podrías poner un
> "sniffer" examinando la conversación en TCP y contar los bytes según el
> protocolo FE/BE.  Debe ser bastante tedioso implementar esto ...
>
> --
> Álvaro Herrerahttp://www.2ndQuadrant.com/
> PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
>



-- 
Cordialmente,

Ing. Hellmuth I. Vargas S.
Esp. Telemática y Negocios por Internet
Oracle Database 10g Administrator Certified Associate
EnterpriseDB Certified PostgreSQL 9.3 Associate

[pgsql-es-ayuda] obtener el tamaño del resultado en una consulta en el log de postgres

[Hellmuth Vargas]

Hola Lista

Quisiera saber si es posible almacenar en el log de PostgreSQL el tamaño en
bytes del resultado de una consulta SELECT, o en otras palabras, poder
registrar en el log de PostgreSQL cuantos bytes pesa el resultado devuelto
por las sentencias SELECT. De antemano muchas gracias

-- 
Cordialmente,

Ing. Hellmuth I. Vargas S.
Esp. Telemática y Negocios por Internet

Re: [pgsql-es-ayuda] bases de datos con secuencias solo pares o impares

[Hellmuth Vargas]

Hola Gerardo

Muchas gracias por su respuesta: con automático me refiero a tener la
posibilidad de definir un "trigger" que cuando se cree o altere la
secuencia el procedimiento pueda ajustarla para que sea par (o impar, según
el caso). Esto es porque no tengo control sobre el desarrollo y
configuración  que hacen los desarrolladores de Hibernate, ellos hacen
despliegues en cualquier momento (7x24)

El 14 de junio de 2016, 20:50, Gerardo Herzig<gher...@fmed.uba.ar> escribió:

> Supongo que con automatico querras decir "definido al momento de creacion".
> Fijate que cuando definis un campo serial, internamente crea una sequence
> y se la asocia al campo. Algo asi (untested):
>
> CREATE SEQUENCE numerador_par increment by 2 START 2;
> create table numeros_pares (id integer not null default
> nextval('numerador_par'), data text);
>
>
> Algo similar podes hacer para asociar una secuencia que comience con 1,
> incrementos de a 2, dandote asi numeros impares.
>
> HTH
> Gerardo
>
> - Mensaje original -
> > De: "Hellmuth Vargas" <hiv...@gmail.com>
> > Para: "raul andrez gutierrez alejo" <rauland...@gmail.com>
> > CC: "Lista Postgres ES" <pgsql-es-ayuda@postgresql.org>
> > Enviados: Martes, 14 de Junio 2016 12:26:54
> > Asunto: Re: [pgsql-es-ayuda] bases de datos con secuencias solo pares o
> impares
> >
> >
> > Hola Lista
> >
> >
> > Muchas gracias por la respuesta, pero se requiere qeu sea automático
> > porque se están generando varias tablas en diferente tiempo por
> > varios desarrolladores y mientras que se detecta la creación podría
> > insertarse valores pares en una base impar. Por eso en principio
> > explore el tema de Event Triggers
> >
> >
> > El 14 de junio de 2016, 10:06, raul andrez gutierrez alejo <
> > rauland...@gmail.com > escribió:
> >
> >
> >
> > seria así:
> >
> > ALTER SEQUENCE nombre_secuencia INCREMENT 2;
> >
> >
> >
> >
> >
> >
> > El 14 de junio de 2016, 9:52, Alejandra Bautista <
> > alejandrab...@gmail.com > escribió:
> >
> >
> >
> >
> >
> > Hola:
> >
> > Podrías iniciar tu secuencia en 1 o en 2 y en el increment porner el
> > número 2.
> >
> > Saludos!
> >
> >
> >
> >
> >
> > El 14 de junio de 2016, 8:18, Hellmuth Vargas < hiv...@gmail.com >
> > escribió:
> >
> >
> >
> > Hola Lista
> >
> >
> > Tengo varias base de datos PostgreSQL con varias aplicación con
> > Hibenate donde a cada momento realizan nuevos desarrollos creado
> > nuevas tablas y sus correspondiente secuencias. Quisiera
> > preguntarles como podría implementar la manera que siempre que se
> > creen secuencias en la base de datos esta sean pares o impares
> > automaticamente. He estado revisando el tema de los Event Triggers
> > mas no logro que altere la secuencia. De antemano les agradezco su
> > atención.
> >
> >
> >
> > --
> >
> >
> > Cordialmente,
> >
> > Ing. Hellmuth I. Vargas S.
> > Esp. Telemática y Negocios por Internet
> >
> >
> >
> >
> >
> >
> > --
> >
> > Raul Andres Gutierrez Alejo
> >
> >
> >
> > --
> >
> >
> > Cordialmente,
> >
> > Ing. Hellmuth I. Vargas S.
> > Esp. Telemática y Negocios por Internet
> > Oracle Database 10g Administrator Certified Associate
> >
> > EnterpriseDB Certified PostgreSQL 9.3 Associate
> >
> >
>



-- 
Cordialmente,

Ing. Hellmuth I. Vargas S.
Esp. Telemática y Negocios por Internet
Oracle Database 10g Administrator Certified Associate
EnterpriseDB Certified PostgreSQL 9.3 Associate

Re: [pgsql-es-ayuda] Obtener fechas mas cercanas

[Hellmuth Vargas]

Hola Lista

Lo genere con la siguiente sentencia:

SELECT a.key,a.hora max(b.hora) AS hora_anterior
FROM
(VALUES (1,'21:15'::time),(1,'20:17'::time),(1,'22:15'::time)) AS
a(key,hora)
JOIN
(VALUES
(1,'20:15'::time),(1,'20:16'::time),(1,'21:16'::time),(1,'22:16'::time),(1,'23:16'::time))
AS b(key,hora) ON  a.key=b.key AND a.hora>b.hora
GROUP BY 1,2
ORDER BY  1,2




El 14 de junio de 2016, 15:03, Maximiliano Riffo
escribió:

> Hola estimados, tengo una consulta. Lo que sucede es que tengo dos tablas
> ambas tienen un key y una fecha, entonces lo que debo hacer es traer la
> fecha mas cercana de la otra tabla
> Ejemplo
> tabla b
> key hora
> 1 20:15
> 1 20:16
> 1 21:16
> 1 22:16
> 1 23:16
> tabla a
> key hora
> 1 21:15
> 1 20:17
> 1 22:15
> resultado
> a.key a.hora b.hora anterior
> 1 21:45 21:16
> 1 20:30 20:16
> 1 22:18 22:16
> Para cada registro de la tabla a obtengo la fecha mas cercana anterior de
> la tabla b y que tengan el mismo key.
> Estoy tratando con windows funtions, pero hay algo en lo que fallo. ¿ Esta
> bien que las utilice o existe algo mejor ?.
>
> Las tablas tiene aproximadamente 1 millon de registros cada una.
> Si tuvieran alguna sugerencia.
>
> Saludos y gracias
>
> --
> Max
>
>


-- 
Cordialmente,

Ing. Hellmuth I. Vargas S.
Esp. Telemática y Negocios por Internet
Oracle Database 10g Administrator Certified Associate
EnterpriseDB Certified PostgreSQL 9.3 Associate

[pgsql-es-ayuda] bases de datos con secuencias solo pares o impares

[Hellmuth Vargas]

Hola Lista

Tengo varias  base de datos PostgreSQL con varias aplicación con Hibenate
donde a cada momento realizan nuevos desarrollos creado nuevas tablas y sus
correspondiente secuencias. Quisiera preguntarles  como podría  implementar
la manera que siempre que se  creen secuencias en la base de datos esta
sean pares o impares automaticamente. He estado revisando el tema de los
 Event Triggers mas no logro que altere la secuencia. De antemano les
agradezco su atención.


-- 
Cordialmente,

Ing. Hellmuth I. Vargas S.
Esp. Telemática y Negocios por Internet

[pgsql-es-ayuda] Re: [pgsql-es-ayuda] Create tabla unlogged que elimine automáticamente los registros una vez terminada la función

[Hellmuth Vargas]

Hola Mauricio

Creo que tiene una confusión entre tablas unlogged y tablas temporales,
para lo que desea hacer  las tablas temporales seria lo que esta
buscando...en le siguiente link encuentra un ejemplo:


http://www.sqlines.com/postgresql/statements/create_temporary_table

El 2 de junio de 2016, 17:08, Alvaro Herrera
escribió:

> mauricio pullabuestan escribió:
> > Buen día.
> >
> > Tengo una función que utiliza una tabla temporal con un indice don
> ingreso y actualizo datos, luego hago un update a otras tablas en base a a
> la data de la tabla temporal.
> >
> > Según leí el rendimiento es mejor en una tabla física que una temporal,
> entonces quiero cambiar la tabla temporal con una tabla Unlogged y que al
> final de la función los registros de dicha tabla se eliminen
> automáticamente.
> >
> > Esta función es llamada por varios usuarios, como cada uno tiene su
> propia transacción, los datos serán independientes, por lo cual no habría
> problema con la concurrencia.
> >
> > Mi definición de la tabla seria algo como esto.
> >
> > Create unlogged table miesquema.item_costo
> > (
> > item integer,
> > tiene_componenten boolean,
> > costo numeric(12, 8),
> > ...
> > ) ON COMMIT DELETE ROWS;
> >
> > Pero me lanza un error "On Commit solo puede ser usado con tablas
> > temporales", existe algún mecanismo para vaciar la tabla al salir de
> > la función?
>
> No, pero podrías usar TRUNCATE.
>
> ¿Dónde leíste que una tabla unlogged era mejor que una tabla temporal?
> Hasta donde yo sé, la única diferencia es en qué punto una o la otra se
> van a disco; y para una tabla temporal puedes controlarlo con el
> parámetro temp_buffers.  Quizás podrías probar si mejora poniendo
> temp_buffers en un tamaño donde quepa la tabla completa, para evitar que
> se escriba a disco.
>
> --
> Á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
>



-- 
Cordialmente,

Ing. Hellmuth I. Vargas S.
Esp. Telemática y Negocios por Internet
Oracle Database 10g Administrator Certified Associate
EnterpriseDB Certified PostgreSQL 9.3 Associate

Re: [pgsql-es-ayuda] Usar parametro de FUNCTION como condicion en WHERE

[Hellmuth Vargas]

Buenas tardes Pedro




CREATE OR REPLACE FUNCTION fn_busca_almacen_por_criterio(in_criterio
character varying DEFAULT ''::character varying, in_valor character varying
DEFAULT ''::character varying)
  RETURNS SETOF vw__almacen AS
$BODY$
DECLAREin_criterio alias FOR $1;
in_valoralias FOR $2;

DECLARElr_ret RECORD;
t_consulta TEXT:=$$SELECT * FROM vw__almacen  WHERE $$ || in_criterio
|| $$ LIKE '%$$ || in_valor ||  $$%'$$;

BEGIN
FOR lr_ret IN EXECUTE  t_consulta  LOOP
RETURN NEXT lr_ret;
 END LOOP;
END;$BODY$
  LANGUAGE plpgsql VOLATILE
  COST 100
  ROWS 1000;


2016-05-24 12:45 GMT-05:00 Pedro PG :

> Hola lista, requiero de su ayuda, pues verán, en la siguiente función
> necesito que el primer parametro IN in_criterio represente a la columna en
> donde se buscara y el segundo parametro IN in_valor represente el valor a
> buscar, ¿como es que puedo hacerlo?. He intentado lo siguiente pero no
> funciona, ¿alguna sugerencia?
>
>
> CREATE OR REPLACE FUNCTION fn_busca_almacen_por_criterio(in_criterio
> character varying DEFAULT ''::character varying, in_valor character varying
> DEFAULT ''::character varying)
>   RETURNS SETOF vw__almacen AS
> $BODY$
> DECLAREin_criterio alias FOR $1;
> in_valoralias FOR $2;
>
> DECLARElr_ret RECORD;
> BEGIN
> FOR lr_ret IN
> SELECT*
> FROMvw__almacen
> WHEREin_criterio LIKE CONCAT('%',in_valor,'%')
>  LOOP
> RETURN NEXT lr_ret;
>  END LOOP;
> END;$BODY$
>   LANGUAGE plpgsql VOLATILE
>   COST 100
>   ROWS 1000;
>
> Gracias desde ya.
>
> Saludos.
>



-- 
Cordialmente,

Ing. Hellmuth I. Vargas S.
Esp. Telemática y Negocios por Internet
Oracle Database 10g Administrator Certified Associate
EnterpriseDB Certified PostgreSQL 9.3 Associate

Re: [pgsql-es-ayuda] Fwd: Comando Shell

[Hellmuth Vargas]

Hola Lista

Alguna vez ley sobre PL/sh: Procedural Language Handler for PostgreSQL, mas
nunca lo he probado:

https://github.com/petere/plsh

El 19 de mayo de 2016, 15:59, Edwin Quijada
escribió:

> Para eso tendrias que usar untrusted language , lease plperlu, plpythonu o
> cualquiera que sea u con plpgsql no podras hacerlo
>
>
>
> --
> *From:* pgsql-es-ayuda-ow...@postgresql.org <
> pgsql-es-ayuda-ow...@postgresql.org> on behalf of juan 
> *Sent:* Thursday, May 19, 2016 8:21 PM
> *To:* Mario Jiménez Carrasco
> *Cc:* frank cruzado; pgsql-es-ayuda@postgresql.org
> *Subject:* Re: [pgsql-es-ayuda] Fwd: Comando Shell
>
> \! [comando]
>
> 2016-05-19 17:00 GMT-03:00 Mario Jiménez Carrasco <
> mario.carra...@gmail.com>:
>
>> Quiza esta respuesta te ayude...
>>
>>
>> http://www.postgresql.org/message-id/pine.lnx.4.33.0307241130050.25837-100...@css120.ihs.com
>>
>> Saludos.
>>
>> ISC. Mario Jiménez Carrasco.
>> Subdirección Técnico y de Negocios
>> Desarrollo de Software.
>> Gobierna SCP.
>>
>> 2016-05-19 14:53 GMT-05:00 frank cruzado :
>>
>>>
>>> Estoy migrando un procedimiento almacenado de SQL Server a PostgreSQL y
>>> existe un comando en particular, propio de MSQL, que no logro migrar es el
>>> xp_cmdShell, existe alguna forma de ejecutar un comando en shell del SO
>>> desde PostgreSQL
>>>
>>> Gracias
>>> Frank C.
>>>
>>>
>>
>


-- 
Cordialmente,

Ing. Hellmuth I. Vargas S.
Esp. Telemática y Negocios por Internet
Oracle Database 10g Administrator Certified Associate
EnterpriseDB Certified PostgreSQL 9.3 Associate

Re: [pgsql-es-ayuda] FTS

[Hellmuth Vargas]

Hola Guillermo

En efecto ese es el comportamiento esperado, el indice solo se puede
aplicar sobre la expresión de columna exacta que se definió. Al colocar una
función adicional (en el caso coalesce) esta modificando el valor de la
columna y sobre este nuevo valor no se genero el indice, sucede lo mismo
 si definimos un indice sobre un valor texto, por  ejemplo:

CREATE INDEX idx_tabla_nombre
  ON tabla(nombre);

y luego pretendemos que lo use en una sentencias así:

SELECT * FROM tabla WHERE UPPER(nombre) ='CARLOS'

Si es frecuente la consulta con UPPER debería definir el indice con la
función UPPER (PostgreSQL soporta esto):

CREATE INDEX idx_tabla_upper_nombre
  ON tabla(*UPPER(*nombre*)*);



El 3 de mayo de 2016, 07:56, Guillermo E. Villanueva
escribió:

> Buenos días cómo están?
> Les comento una experiencia con full text search.
> En una tabla que tengo unos 120mil registros creé un índice para hacer FTS
> de la siguiente forma:
> CREATE INDEX fts_escritodtxt
>   ON tescrito
>   USING gin
>   (to_tsvector('spanish'::regconfig, escritodtxt));
>
> cuando hago un explain de la sentencia:
> SELECT
> t.escritoid,
> t.escritofecfirma,
> t.escritotipojuz
> FROM
> tescrito t
> WHERE
> to_tsvector('spanish',coalesce(escritodtxt,''))   @@
> to_tsquery('spanish','hogar & vereda');
>
> Me dice que *no utilizará el índice* creado y con una búsqueda secuencial
> demora aproximadamente 4 minutos.
> Pero si elimino el coalesce, entonces si usa el índice y el resultado se
> obtiene en menos de un segundo!!!
> *¿Es este el comportamiento esperado?* No pasa lo mismo con los índices
> no fts.
> Desde ya muchas gracias por sus comentarios
>
> Saludos
>
> Guillermo
>



-- 
Cordialmente,

Ing. Hellmuth I. Vargas S.
Esp. Telemática y Negocios por Internet
Oracle Database 10g Administrator Certified Associate
EnterpriseDB Certified PostgreSQL 9.3 Associate

Re: [pgsql-es-ayuda] Obtener registros

[Hellmuth Vargas]

Hola Albero

Suponiendo que el Id es la clave para relacionar los registros, eso sale
con un JOIN con la misma  tabla:



WITH base AS (

SELECT * FROM (VALUES
(4,208902,'02','11/02/2015'::date),
(4,208902,'02','16/03/2015'::date),
(4,208902,'02','01/04/2015'::date),
(4 ,404058,'04','20/05/2015'::date),
(4 ,404058,'04','01/07/2015'::date)) as A(Id,Codigo,Tipo_Reg ,Fecha)
)
SELECT a.Id,a.Codigo,a.Tipo_Reg,max(a.Fecha) as ultimo
FROM base as a
JOIN base as b on a.id=b.id and b.tipo_reg='02' and b.Fecha<=a.fecha
WHERE a.Tipo_Reg='04'
GROUP BY  a.Id,a.Codigo,a.Tipo_Reg



El 28 de abril de 2016, 09:02, Alberto Cuevas
escribió:

> Buenos días a todos, tengo una tabla en la cual se registra un tipo de
> registro (Tipo_Reg) y la Fecha, lo que se requiere es obtener solo los
> registros con Tipo_Reg = 04 pero que antes hayan tenido Tipo_Reg = 02.
>
> 
> | Id | Codigo  | Tipo_Reg  | Fecha|
> 
> | 4  |208902  |02 |  11/02/2015 |
> | 4  |208902  |02 |  16/03/2015 |
> | 4  |208902  |02 |  01/04/2015 |
> | 4  |404058  |04 |  20/05/2015 |
> | 4  |404058  |04 |  01/07/2015 |
> 
>
> Alguna idea por favor.
>
> Saludos.
>
>
>


-- 
Cordialmente,

Ing. Hellmuth I. Vargas S.
Esp. Telemática y Negocios por Internet
Oracle Database 10g Administrator Certified Associate
EnterpriseDB Certified PostgreSQL 9.3 Associate

Re: [pgsql-es-ayuda] Como obtener el ultimo registro de un rango de registros

[Hellmuth Vargas]

Hola Edwin

Propongo esta solución empleado Windows Functions, (solo requeriría la
parte en negrilla, lo de arriba es para poder ejecutar el query con los
datos proporcionados):


with  events as (
select * from (values
('1','56','1',100,'03/01/16 00:00'::timestamp),
('2','62','1',100,'04/01/16 00:00'::timestamp),
('3','62','2',100,'03/01/16 20:45'::timestamp),
('4','56','1',100,'04/01/16 10:00'::timestamp),
('5','56','9',200,'03/01/16 00:00'::timestamp),
('6','62','1',200,'04/01/16 15:00'::timestamp),
('7','56','1',100,'07/01/16 00:00'::timestamp),
('8','62','1',100,'09/01/16 00:00'::timestamp),
('9','62','1',100,'09/01/16 13:00'::timestamp),
('10','56','1',100,'09/01/16 15:12'::timestamp)) as
a(idevent,idevettype,zu,idaccount,dateevent)

)
*select idevent,idevettype,zu,idaccount,de*
*FROM (*
*  SELECT idevent,idevettype, zu, idaccount,dateevent,
MAX(dateevent) over(partition by idevettype, zu, idaccount) AS de FROM
 events*
*  where (idaccount = 100 OR idaccount = 200) *
*) as y WHERE dateevent=de*
*ORDER BY 2,3,4*







El 27 de abril de 2016, 08:22, Edwin De La Cruz
escribió:

> Saludos cordiales.
> Tengo una tabla cuyos campos relevantes son:
> idevent idevettype zu idaccount dateevent
> 1 56 1 100 03/01/16 00:00
> 2 62 1 100 04/01/16 00:00
> 3 62 2 100 03/01/16 20:45
> 4 56 1 100 04/01/16 10:00
> 5 56 9 200 03/01/16 00:00
> 6 62 1 200 04/01/16 15:00
> 7 56 1 100 07/01/16 00:00
> 8 62 1 100 09/01/16 00:00
> 9 62 1 100 09/01/16 13:00
> 10 56 1 100 09/01/16 15:12
>
> Y necesito una consulta que me devuelva algo asi:
>
> idevent idevettype zu idaccount dateevent
> 10 56 1 100 09/01/16 15:12
> 9 62 1 100 09/01/16 13:00
> 6 62 1 200 04/01/16 15:00
> 3 62 2 100 03/01/16 20:45
> 5 56 9 200 03/01/16 00:00
>
>
> Usando la consulta:
> SELECT ideventtype, zu, idaccount, MAX(dateevent) AS de FROM  events
> where (idaccount = 100 OR idaccount = 200) GROUP BY ideventtype,
> idaccount, zu;
>
> Me devuelve las filas que esperaría recibir, pero el campo que
> necesito en realidad es el idevent, si agrego esa columna a la
> consulta obtengo el error:
>
> ERROR: la columna «events.idevent» debe aparecer en la cláusula GROUP
> BY o ser usada en una función de agregación
> SQL state: 42803
> Character: 8
>
>
> Quiza sea una pregunta de novato pero he leído y leído y en ningún
> caso he conseguida hacer que funcione como espero.
> Encontré una solución a lo que necesito pero era para SQL SERVER con
> unas funciones que no había visto antes, ahora mismo no recuerdo y no
> reencuentro el link para ponerlo aqui.
>
>
> Espero que alguien que se haya visto en este caso o similar me pueda
> orientar un poco.
>
>
> Mis proyectos de software libre en:
> Github - edwinspire
>
> -
> 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
>



-- 
Cordialmente,

Ing. Hellmuth I. Vargas S.
Esp. Telemática y Negocios por Internet
Oracle Database 10g Administrator Certified Associate
EnterpriseDB Certified PostgreSQL 9.3 Associate

Re: [pgsql-es-ayuda] modos de bloqueo

[Hellmuth Vargas]

Hola Lista

Quisiera  que aclaráramos y dividiéramos el problema en cuestión:  la
necesitad del bloqueo es por los Item o artículos que hacen parte de la
factura para que otro cliente nos los vaya a tomar nuestros artículos
mientras se efectúa la factura o es por el numero de la factura? Porque
según estoy entendiendo en el hilo de la discusión  el tema es el numero de
facturación, si es así no hay necesidad de bloquear las tablas, el tema es
con la secuencia que genera el numero de factura, que no debe tener saltos,
debe ser consecutivo, debe ser UNICO, que debe corresponder a un rango
valido, etc. etc y el enfoque es diferente para lograr esto de forma
concurrente.

El 21 de abril de 2016, 07:29, Kernel escribió:

> El 20/04/2016 a las 22:56, Jaime Casanova escribió:
>
>> 2016-04-19 13:15 GMT-05:00 Francisco Olarte :
>>
>>> 2016-04-19 19:55 GMT+02:00 Kernel :
>>>
 Voy a hacer un proceso de facturacion y necesito asegurar que nadie
 pueda
 facturar en el mismo momento que yo.
 Necesito bloquear una tabla de manera que nadie pueda hacer un insert,
 update o delete, solo pueda leer de la tabla pero nada mas hasta que
 termine
 el trabajo.

 ¿CUAL SERIA EL TIPO DE BLOQUEO MAS ADECUADO?

>>>
>>> Buff, probablemente LOCK EXCLUSIVE, que da conflicto con todo menos
>>> con el select si no recuerdo mal, mirando ademas el nivel de
>>> aislamiento que necesitas.
>>>
>>>
>> Bastaría con LOCK SHARE (evita modificaciones concurrentes).
>>
>> Ahora, si lo que quieres es evitar que te incrementen el número
>> secuencial, debería ser suficiente
>> agregar un FOR UPDATE al cursor llamado albaranes.
>>
>> Por cierto, esto es 4gl?
>>
>>
> Si un usuario lanza un proceso para generar 200 facturas , no puedo
> permitir que otro usuario intercale un numero de factura, pero tampoco
> quiero que otro usuario lance otro proceso y se le quede bloqueado hasta
> que termine el otro usuario (ya conocemos a los usuarios..).
>
> Estoy pensando en bloquear a nivel de tabla,crear una tabla en la que
> contenga  proceso,empresa,serie
>
> Cuando un proceso se inicie se debe de bloquear el registro con un select
> for update, pero antes debe de comprobar que no lo ha bloqueado otro
> usuario y asi poder mandar un aviso al usuario de que lo intente mas tarde.
>
>
> ¿hay alguna manera de saber si un registro esta bloqueado y evitar la
> espera?
>
> 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
>



-- 
Cordialmente,

Ing. Hellmuth I. Vargas S.
Esp. Telemática y Negocios por Internet
Oracle Database 10g Administrator Certified Associate
EnterpriseDB Certified PostgreSQL 9.3 Associate

[pgsql-es-ayuda] Re: [pgsql-es-ayuda] Separación lógica de tablas, agrega rendimiento?

[Hellmuth Vargas]

Hola Ivan

PostgreSQL esta en capacidad de forma 'automática' los diferentes tablas
que  hacen parte de la un partición, el tema del procedimiento es que si
diseña bien la clave de partición la definición del Procedimiento  es
sencillo y de mantenimiento  muy espaciado en el tiempo (incluso puede ser
hasta nulo). Incluso existen extensión que definen y crean todo lo
necesario para la definición y gestión de particiones (por
ejemplo pg_pathman por mencionar una reciente publicada). La potencia del
tema es que una vez definido, es prácticamente transparente, pues es el
motor se encarga de seleccionar la partición apropiada tanto para las
operaciones DML como para las consultas. Vuelvo y reitero, el asunto es
definir  claramente la clave de partición, ojala qeu permita que la
informacion se distribuya uniformemente entre las particiones, las
consideraciones son variadas, las tablas tiene  fecha de creación? se
pueden crear particiones mensuales, ademas puede participarse por cliente?
(clave compuesta)...

El 19 de abril de 2016, 14:07, Ivan Perales M.
escribió:

> Que tal buenas tardes.
>
> Me gustaria su opinion sobre lo siguiente. Hace varios años que se hizo un
> sistema para logistica de material. Con el paso de los años, dos tablas
> principales crecieron al grado de tener millones de registros, una es la
> que representa cada caja de material y la otra es los movimientos de
> material.
>
> El sistema obviamente es para muchos clientes, por lo que cada tabla tiene
> registros de todos los clientes y una columna que los indentifica. Y como
> en todo negocio, hay clientes chicos y clientes grandes. Clientes que
> manejan tan poco volumen que sus movimientos llegan a varios miles y otros
> con varios cientos de miles.
>
> Cuando se hace una consulta para un cliente pequeño en esas tablas, el
> tiempo del query es mucho mayor a que si solo buscara en los registros
> propios del cliente y esto es obvio, es por que tambien busca entre los
> registros de los otros clientes.
>
> Buscando en internet como optimizar esto, encontre un blog que decia que
> para optimizar el rendimiento de tablas grandes se deberia utilizar la
> partición de tablas, que básicamente son muchas tablas hijas, donde un
> store procedure decide a que tabla hija enviar la información.
>
>
> Mi pregunta es, si creo un schema para cada cliente teniendo las mismas
> tablas, entonces esta separación logica trabajaria igual que la particion
> de tablas no? la diferencia es que seria desde el software donde se indique
> a que schema guardar y no mediante un store procedure. Realizar esta
> separación realmente si trae ventajas en lugar de utilizar una sola tabla
> para todos los clientes?
>
> Saludos y gracias por su tiempo.
>
> --
> Lindolfo Iván Perales Mancinas
> Solo existen 10 tipos de personas en el mundo, las que saben binario y las
> que no.
>



-- 
Cordialmente,

Ing. Hellmuth I. Vargas S.
Esp. Telemática y Negocios por Internet
Oracle Database 10g Administrator Certified Associate
EnterpriseDB Certified PostgreSQL 9.3 Associate

Re: [pgsql-es-ayuda] Restar dos campos de tipo fecha de distintos registros

[Hellmuth Vargas]

-- Mensaje enviado --
De: Hellmuth Vargas <hiv...@gmail.com>
Fecha: 18 de abril de 2016, 13:18
Asunto: Re: [pgsql-es-ayuda] Restar dos campos de tipo fecha de distintos
registros
Para: Alberto Cuevas <betocuevas@gmail.com>
CC: Gerardo Herzig <gher...@fmed.uba.ar>, Lista Postgres ES <
pgsql-es-ayuda@postgresql.org>



Hola lista

Con Window Functions (
http://www.postgresql.org/docs/9.4/static/tutorial-window.html) puede
realizar eso...para el problema especifico seria asi:


SELECT  *,
LAG(FechaInicial) over(order by Ord),FechaFinal-LAG(FechaInicial)
over(order by Ord) as diferencia
from (values (1,cast('01/10/2015' as date),cast('01/12/2015' as date)),
(2,cast('01/08/2015' as date),cast('01/10/2015' as date)),
(3,cast('01/06/2015' as date),cast('01/08/2015' as date)),
(4,cast('01/05/2015' as date),cast('01/06/2015' as date)),
(5,cast('01/04/2015' as date),cast('01/05/2015' as date)),
(6,cast('01/03/2015' as date),cast('01/04/2015' as date)),
(7,cast('01/02/2015' as date),cast('01/03/2015' as date)),
(8,cast('01/01/2015' as date),cast('28/01/2015' as date)),
(9,cast('01/12/2014' as date),cast('01/01/2015' as date)),
(10,cast('01/11/2014' as date),cast('01/12/2014' as date))) as
a(Ord,FechaInicial,FechaFinal)


con resultado

Ord FechaInicial FechaFinal fechaInicialFilaAnterior Diferencia
1 2015-10-01 2015-12-01

2 2015-08-01 2015-10-01 2015-10-01 0
3 2015-06-01 2015-08-01 2015-08-01 0
4 2015-05-01 2015-06-01 2015-06-01 0
5 2015-04-01 2015-05-01 2015-05-01 0
6 2015-03-01 2015-04-01 2015-04-01 0
7 2015-02-01 2015-03-01 2015-03-01 0
8 2015-01-01 2015-01-28 2015-02-01 -4
9 2014-12-01 2015-01-01 2015-01-01 0
10 2014-11-01 2014-12-01 2014-12-01 0


El 18 de abril de 2016, 15:50, Alvaro Herrera<alvhe...@2ndquadrant.com>
escribió:

> Alberto Cuevas escribió:
> > Muchas gracias por responder, disculpen por no dar un ejemplo mas claro,
> mi
> > tabla tiene los registros similar a esto:
> >
> > |Ord. | FechaInicial | FechaFinal |
> > |1  | 01/10/2015  | 01/12/2015 |
> > |2  | 01/08/2015  | 01/10/2015 |
> > |3  | 01/06/2015  | 01/08/2015 |
> > |4  | 01/05/2015  | 01/06/2015 |
> > |5  | 01/04/2015  | 01/05/2015 |
> > |6  | 01/03/2015  | 01/04/2015 |
> > |7  | 01/02/2015  | 01/03/2015 |
> > |8  | 01/01/2015  | 28/01/2015 |
> > |9  | 01/12/2014  | 01/01/2015 |
> > |10| 01/11/2014  | 01/12/2014 |
> >
> > Debo restar FechaFinal - FechaInicial es decir:
> >
> > FechaFinal de Ord. 2 - FechaInicial de Ord.1 = 0 dias
> > FechaFinal de Ord. 3 - FechaInicial de Ord.2 = 0 dias
> > ..
> > Y asi sucesivamente..
>
> La función ventana LAG() puede retornar el valor en el registro
> anterior; o si declaras ventanas de tamaño uno, la función first_value()
> debería servir también.  Ver
> http://www.postgresql.org/docs/current/static/functions-window.html
>
> --
> Á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
>



-- 
Cordialmente,

Ing. Hellmuth I. Vargas S.
Esp. Telemática y Negocios por Internet
Oracle Database 10g Administrator Certified Associate
EnterpriseDB Certified PostgreSQL 9.3 Associate

Re: [pgsql-es-ayuda] Restar dos campos de tipo fecha de distintos registros

[Hellmuth Vargas]

Hola Lista

El 18 de abril de 2016, 14:55, Gerardo Herzig escribió:

> Un registro no "conoce" al registro proximo ni al anterior.


Gerardo, con Window Functions (
http://www.postgresql.org/docs/9.4/static/tutorial-window.html) si es
posible conocer el anterior o el siguiente de un registro...



> Basicamente se me ocurren estas maneras:
> postgres=# select * from test;
>  ord | fechainicial | fechafinal
> -+--+
>1 | 2015-10-01   | 2015-12-01
>2 | 2015-08-01   | 2015-10-01
>3 | 2015-06-01   | 2015-08-01
>4 | 2015-05-01   | 2015-06-01
>5 | 2015-04-01   | 2015-05-01
>6 | 2015-03-01   | 2015-04-01
>7 | 2015-02-01   | 2015-03-01
>8 | 2015-01-01   | 2015-01-28
>9 | 2014-12-01   | 2015-01-01
>   10 | 2014-11-01   | 2014-12-01
> (10 filas)
>
> postgres=# select *, fechafinal - (select fechainicial from test where ord
> = t.ord - 1) from test t;
>  ord | fechainicial | fechafinal | ?column?
> -+--++--
>1 | 2015-10-01   | 2015-12-01 |
>2 | 2015-08-01   | 2015-10-01 |0
>3 | 2015-06-01   | 2015-08-01 |0
>4 | 2015-05-01   | 2015-06-01 |0
>5 | 2015-04-01   | 2015-05-01 |0
>6 | 2015-03-01   | 2015-04-01 |0
>7 | 2015-02-01   | 2015-03-01 |0
>8 | 2015-01-01   | 2015-01-28 |   -4
>9 | 2014-12-01   | 2015-01-01 |0
>   10 | 2014-11-01   | 2014-12-01 |0
> (10 filas)
>
> 2) Usando pl/pgsql, abris un cursor y recorres registro por registro,
> haciendo un select similar al (subselect) de mas arriba,
>
> 3) Calculo que con recursive with puede llegarse a algo, pero me estoy
> equivocando en algo y no me sale bien.
>
> HTH
> Gerardo
>
> - Mensaje original -
> > De: "Alberto Cuevas" 
> > Para: "Gerardo Herzig" 
> > CC: pgsql-es-ayuda@postgresql.org
> > Enviados: Lunes, 18 de Abril 2016 15:03:22
> > Asunto: Re: [pgsql-es-ayuda] Restar dos campos de tipo fecha de
> distintos registros
> >
> >
> > Muchas gracias por responder, disculpen por no dar un ejemplo mas
> > claro, mi tabla tiene los registros similar a esto:
> >
> >
> > |Ord. | FechaInicial | FechaFinal |
> > |1 | 01/10/2015 | 01/12/2015 |
> > |2 | 01/08/2015 | 01/10/2015 |
> > |3 | 01/06/2015 | 01/08/2015 |
> > |4 | 01/05/2015 | 01/06/2015 |
> > |5 | 01/04/2015 | 01/05/2015 |
> > |6 | 01/03/2015 | 01/04/2015 |
> > |7 | 01/02/2015 | 01/03/2015 |
> > |8 | 01/01/2015 | 28/01/2015 |
> > |9 | 01/12/2014 | 01/01/2015 |
> > |10 | 01/11/2014 | 01/12/2014 |
> >
> >
> > Debo restar FechaFinal - FechaInicial es decir:
> >
> >
> > FechaFinal de Ord. 2 - FechaInicial de Ord.1 = 0 dias
> > FechaFinal de Ord. 3 - FechaInicial de Ord.2 = 0 dias
> > ..
> >
> > Y asi sucesivamente..
> >
> >
> > Espero me puedan entender.
> >
> >
> > Saludos.
> >
> >
> >
> >
> >
> > El lun., 18 abr. 2016 a las 12:20, Gerardo Herzig (<
> > gher...@fmed.uba.ar >) escribió:
> >
> >
> > Vas a tener que orquestar 2 selects distintos para sacar tu "fecha
> > inicial" y tu "fecha final". Supongo que tu tabla de ejemplo es
> > esquematica, pero mas alla de la posible complejidad del select, el
> > tipo date soporta el operador de resta "habitual":
> >
> > (select fechafinal from TABLA where ord = 1) - (select fechainicial
> > from TABLA where ord=2)
> >
> > En tu ejemplo, el resultado seria negativo, por cierto, pero calculo
> > que eso lo podras contemplar.
> > HTH
> > Gerardo
> > - Mensaje original -
> > > De: "Alberto Cuevas" < betocuevas@gmail.com >
> > > Para: pgsql-es-ayuda@postgresql.org
> > > Enviados: Lunes, 18 de Abril 2016 13:36:18
> > > Asunto: [pgsql-es-ayuda] Restar dos campos de tipo fecha de
> > > distintos registros
> > >
> > >
> > >
> > >
> > >
> > >
> > > Hola a todos necesito restar dos campos de tipo fecha de distintos
> > > registros.
> > >
> > > FechaFinal - FechaInicial
> > >
> > > | Ord. | FechaInicial | FechaFinal |
> > > | 2 | 26/02/2016 | 02/03/2016 |
> > > | 1 | 18/02/2016 | 24/02/2016 |
> > >
> > > 24/02/2016 - 26/02/2016 = 2 dias
> > >
> > > Por favor si me pueden ayudar .
> > >
> > > Saludos
> > >
> > >
> > >
> > >
> > >
> > >
> >
>
> -
> 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
>



-- 
Cordialmente,

Ing. Hellmuth I. Vargas S.
Esp. Telemática y Negocios por Internet
Oracle Database 10g Administrator Certified Associate
EnterpriseDB Certified PostgreSQL 9.3 Associate

Re: [pgsql-es-ayuda] Restar dos campos de tipo fecha de distintos registros

[Hellmuth Vargas]

Hola lista

Con Window Functions (
http://www.postgresql.org/docs/9.4/static/tutorial-window.html) puede
realizar eso...para el problema especifico seria asi:


SELECT  *,lag(FechaInicial) over(order by Ord),FechaFinal-lag(FechaInicial)
over(order by Ord) as diferencia
from (values (1,cast('01/10/2015' as date),cast('01/12/2015' as date)),
(2,cast('01/08/2015' as date),cast('01/10/2015' as date)),
(3,cast('01/06/2015' as date),cast('01/08/2015' as date)),
(4,cast('01/05/2015' as date),cast('01/06/2015' as date)),
(5,cast('01/04/2015' as date),cast('01/05/2015' as date)),
(6,cast('01/03/2015' as date),cast('01/04/2015' as date)),
(7,cast('01/02/2015' as date),cast('01/03/2015' as date)),
(8,cast('01/01/2015' as date),cast('28/01/2015' as date)),
(9,cast('01/12/2014' as date),cast('01/01/2015' as date)),
(10,cast('01/11/2014' as date),cast('01/12/2014' as date))) as
a(Ord,FechaInicial,FechaFinal)


con resultado

Ord FechaInicial FechaFinal fechaInicialFilaAnterior Diferencia
1 2015-10-01 2015-12-01

2 2015-08-01 2015-10-01 2015-10-01 0
3 2015-06-01 2015-08-01 2015-08-01 0
4 2015-05-01 2015-06-01 2015-06-01 0
5 2015-04-01 2015-05-01 2015-05-01 0
6 2015-03-01 2015-04-01 2015-04-01 0
7 2015-02-01 2015-03-01 2015-03-01 0
8 2015-01-01 2015-01-28 2015-02-01 -4
9 2014-12-01 2015-01-01 2015-01-01 0
10 2014-11-01 2014-12-01 2014-12-01 0






El 18 de abril de 2016, 13:03, Alberto Cuevas
escribió:

> Muchas gracias por responder, disculpen por no dar un ejemplo mas claro,
> mi tabla tiene los registros similar a esto:
>
> |Ord. | FechaInicial | FechaFinal |
> |1  | 01/10/2015  | 01/12/2015 |
> |2  | 01/08/2015  | 01/10/2015 |
> |3  | 01/06/2015  | 01/08/2015 |
> |4  | 01/05/2015  | 01/06/2015 |
> |5  | 01/04/2015  | 01/05/2015 |
> |6  | 01/03/2015  | 01/04/2015 |
> |7  | 01/02/2015  | 01/03/2015 |
> |8  | 01/01/2015  | 28/01/2015 |
> |9  | 01/12/2014  | 01/01/2015 |
> |10| 01/11/2014  | 01/12/2014 |
>
> Debo restar FechaFinal - FechaInicial es decir:
>
> FechaFinal de Ord. 2 - FechaInicial de Ord.1 = 0 dias
> FechaFinal de Ord. 3 - FechaInicial de Ord.2 = 0 dias
> ..
> Y asi sucesivamente..
>
> Espero me puedan entender.
>
> Saludos.
>
>
> El lun., 18 abr. 2016 a las 12:20, Gerardo Herzig ()
> escribió:
>
>> Vas a tener que orquestar 2 selects distintos para sacar tu "fecha
>> inicial" y tu "fecha final". Supongo que tu tabla de ejemplo es
>> esquematica, pero mas alla de la posible complejidad del select, el tipo
>> date soporta el operador de resta "habitual":
>>
>> (select fechafinal from TABLA where ord = 1) - (select fechainicial from
>> TABLA where ord=2)
>>
>> En tu ejemplo, el resultado seria negativo, por cierto, pero calculo que
>> eso lo podras contemplar.
>> HTH
>> Gerardo
>> - Mensaje original -
>> > De: "Alberto Cuevas" 
>> > Para: pgsql-es-ayuda@postgresql.org
>> > Enviados: Lunes, 18 de Abril 2016 13:36:18
>> > Asunto: [pgsql-es-ayuda] Restar dos campos de tipo fecha de distintos
>> registros
>> >
>> >
>> >
>> >
>> >
>> >
>> > Hola a todos necesito restar dos campos de tipo fecha de distintos
>> > registros.
>> >
>> > FechaFinal - FechaInicial
>> >
>> > | Ord. | FechaInicial | FechaFinal |
>> > | 2 | 26/02/2016 | 02/03/2016 |
>> > | 1 | 18/02/2016 | 24/02/2016 |
>> >
>> > 24/02/2016 - 26/02/2016 = 2 dias
>> >
>> > Por favor si me pueden ayudar .
>> >
>> > Saludos
>> >
>> >
>> >
>> >
>> >
>> >
>>
>


-- 
Cordialmente,

Ing. Hellmuth I. Vargas S.
Esp. Telemática y Negocios por Internet
Oracle Database 10g Administrator Certified Associate
EnterpriseDB Certified PostgreSQL 9.3 Associate

Re: [pgsql-es-ayuda] Mantenimiento a base de datos

[Hellmuth Vargas]

Hola Lista

Y se me olvidaba, el AUTOVACUUM habilitado todo el tiempo..

El 7 de abril de 2016, 07:59, Hellmuth Vargas<hiv...@gmail.com> escribió:

> Hola Lista
>
> Yo creo que depende mucho del nivel transaccional que tenga la base de
> datos y de la disponibilidad de la misma para definir el plan de
> mantenimiento: en mi caso, para bases  7/24 y con una carga de
> transacciones considerable, hice el siguiente plan:
>
> REINDEX solo sobre aquellos indices con alto nivel de fragmentación, para
> esto me base en el articulo  New New Index Bloat Query (
> http://www.databasesoup.com/2014/04/new-new-index-bloat-query.html) y
> envío  REINDEX solo sobre los indices  seleccionados
> - VACUUM  (no FULL y con  ANALYZE) sobre todas las tablas, en las horas de
> baja carga.
> - BACKUP en caliente de la base de datos.
> -
> - VACUUM freeze fines de semana en horas de baja carga sobre todas las
> tablas de la base
>
> Ahora, creo que maría pregunta también sobre el orden se ejecución de las
> instrucciones: si primero REINDEX y luego VACUUM, creo que la secuencia
> lógica es REINDEX y luego VACUUM.
>
>
> El 6 de abril de 2016, 18:43, Gerardo Herzig<gher...@fmed.uba.ar>
> escribió:
>
>> Sabe que tanto vacuum full como reindex van a bloquear la tabla contra
>> otras consultas de "lectura" a las tablas afectadas. Asegurate de avisar
>> y/o conseguir una ventana de downtime.
>>
>> Durante el proceso, te convendra subir la variable maintenance_work_mem a
>> una porcion considerable de la RAM, asi el proceso sera mas rapido.
>>
>> HTH,
>> Gerardo
>>
>> - Mensaje original -
>> > De: "MARIA ANTONIETA RAMIREZ SOLIS" <marami...@ulsaneza.edu.mx>
>> > Para: "FORO POSTGRES" <pgsql-es-ayuda@postgresql.org>
>> > Enviados: Miércoles, 6 de Abril 2016 15:48:22
>> > Asunto: [pgsql-es-ayuda] Mantenimiento a base de datos
>> >
>> >
>> >
>> >
>> >
>> >
>> > Buena tarde
>> >
>> >
>> > Les agradezco el tiempo tomado para leer mi correo...
>> >
>> >
>> > Tengo una duda, quiero hacer mantenimiento en mi base de datos
>> > postgresql version 9.4, cual es la mejor forma de hacerlo, primero
>> > correr el vacumm full y despues la reindexacion?
>> >
>> >
>> > Sin mas por el momento quedo en espera de sus comentarios
>> >
>> >
>> > 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
>>
>
>
>
> --
> Cordialmente,
>
> Ing. Hellmuth I. Vargas S.
> Esp. Telemática y Negocios por Internet
> Oracle Database 10g Administrator Certified Associate
> EnterpriseDB Certified PostgreSQL 9.3 Associate
>
>


-- 
Cordialmente,

Ing. Hellmuth I. Vargas S.
Esp. Telemática y Negocios por Internet
Oracle Database 10g Administrator Certified Associate
EnterpriseDB Certified PostgreSQL 9.3 Associate

Re: [pgsql-es-ayuda] Mantenimiento a base de datos

[Hellmuth Vargas]

Hola Lista

Yo creo que depende mucho del nivel transaccional que tenga la base de
datos y de la disponibilidad de la misma para definir el plan de
mantenimiento: en mi caso, para bases  7/24 y con una carga de
transacciones considerable, hice el siguiente plan:

REINDEX solo sobre aquellos indices con alto nivel de fragmentación, para
esto me base en el articulo  New New Index Bloat Query (
http://www.databasesoup.com/2014/04/new-new-index-bloat-query.html) y envío
 REINDEX solo sobre los indices  seleccionados
- VACUUM  (no FULL y con  ANALYZE) sobre todas las tablas, en las horas de
baja carga.
- BACKUP en caliente de la base de datos.
-
- VACUUM freeze fines de semana en horas de baja carga sobre todas las
tablas de la base

Ahora, creo que maría pregunta también sobre el orden se ejecución de las
instrucciones: si primero REINDEX y luego VACUUM, creo que la secuencia
lógica es REINDEX y luego VACUUM.


El 6 de abril de 2016, 18:43, Gerardo Herzig escribió:

> Sabe que tanto vacuum full como reindex van a bloquear la tabla contra
> otras consultas de "lectura" a las tablas afectadas. Asegurate de avisar
> y/o conseguir una ventana de downtime.
>
> Durante el proceso, te convendra subir la variable maintenance_work_mem a
> una porcion considerable de la RAM, asi el proceso sera mas rapido.
>
> HTH,
> Gerardo
>
> - Mensaje original -
> > De: "MARIA ANTONIETA RAMIREZ SOLIS" 
> > Para: "FORO POSTGRES" 
> > Enviados: Miércoles, 6 de Abril 2016 15:48:22
> > Asunto: [pgsql-es-ayuda] Mantenimiento a base de datos
> >
> >
> >
> >
> >
> >
> > Buena tarde
> >
> >
> > Les agradezco el tiempo tomado para leer mi correo...
> >
> >
> > Tengo una duda, quiero hacer mantenimiento en mi base de datos
> > postgresql version 9.4, cual es la mejor forma de hacerlo, primero
> > correr el vacumm full y despues la reindexacion?
> >
> >
> > Sin mas por el momento quedo en espera de sus comentarios
> >
> >
> > 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
>



-- 
Cordialmente,

Ing. Hellmuth I. Vargas S.
Esp. Telemática y Negocios por Internet
Oracle Database 10g Administrator Certified Associate
EnterpriseDB Certified PostgreSQL 9.3 Associate

Re: [pgsql-es-ayuda] Logical Replication en 9.4

[Hellmuth Vargas]

Hola Alberto

Por  un lado creo que  implemento replication_slots para manejar de forma
mas razonable los WAL pendientes por enviar al esclavo,
pero precisamente este mecanismo significa que si el esclavo  consumidor de
ese slot  queda fuera de linea, los WAL se acumularan (en el maestro) hasta
 que el esclavo vuelva a estar presente y pueda retomar la sincronizacion
desde el ultimo WAL confirmado.

Por otro lado, tengo entendido que la replicacion lógica  se implementa
cuando se desea hacer algún procesamiento adicional  (replicacion parcial,
extraer las sentencias ejecutadas, en un futuro la replicacion
bidireccional, etc, etc.), si no es el caso con wal_level = hot_standby
seria suficiente.

El 14 de marzo de 2016, 13:15, Mario Soto Cordones<
marioa.soto.cordo...@gmail.com> escribió:

> Hola Alberto:
>
>
>
> Veo en tu configuración que tienes definido el parámetro
>
>
>
> wal_keep_segments = 5
>
>
>
> creo que este parámetro funciona solo con stream replication y no con
> logical replication, ya que el objetivo de éste método de replicación, es
> precisamente que los archivos de wal se guarden hasta que el servidor
> esclavo vuelva a estar on line, o lo saques del pool de servidores mediante
> un pg_drop_replication_slot(‘esclavo)
>
>
>
> Saludos
>
>
>
> Mario Soto
>
>
>
> *De:* pgsql-es-ayuda-ow...@postgresql.org [mailto:
> pgsql-es-ayuda-ow...@postgresql.org] *En nombre de *alberto cordones
> *Enviado el:* lunes, 14 de marzo de 2016 15:08
> *Para:* pgsql-es-ayuda@postgresql.org
> *Asunto:* [pgsql-es-ayuda] Logical Replication en 9.4
>
>
>
> Hola lista, soy nuevo por aca y me animo a escribir para hacerles una
> pregunta
>
>
>
> Tengo instalado postgresql 9.4 en dos servidores, y quiero pasar de stream
> replication a logical replication, para ello, configuré lo siguiente:
>
>
>
> MASTER:
>
>
>
>
>
> #REPLICACION
>
>
>
> wal_level = logical
>
> max_wal_senders = 3
>
> max_replication_slots = 3
>
> max_worker_processes = 3
>
> hot_standby = on
>
> wal_keep_segments = 5   # in logfile segments, 16MB each; 0 disables
>
>
>
>
>
> hice todo el procedimiento que esta en la documentacion y funciona todo
> muy bien con excelentes resultados hasta ahora. Sin embargo tengo una gran
> duda y no sé como resolverla.
>
>
>
> Si mi nodo esclavo queda fuera de linea, los archivos de wal, ubicados en
> el directorio pg_xlog, del nodo master, comienzan a aumentar de forma
> considerable, hasta que el nodo esclavo queda on line nuevamente.
>
>
>
> Mi temor es que si quedo fuera de linea por mucho tiempo y no me doy
> cuenta, lo mas probable es que me quede sin espacio en el directorio
> pg_xlog y como consecuencia de esto el nodo master deje de atender.
>
>
>
> Saludos
>
>
>
> Alberto
>
>
>



-- 
Cordialmente,

Ing. Hellmuth I. Vargas S.
Esp. Telemática y Negocios por Internet
Oracle Database 10g Administrator Certified Associate
EnterpriseDB Certified PostgreSQL 9.3 Associate

Re: [pgsql-es-ayuda] test de Vitesse DB

[Hellmuth Vargas]

Hola Alvaro

Si efectivamente probé usando pg_upgrade de la estándar y genera error: en
la actualización parece que al levantar el servicio durante la migración
válida o requiere que halla sido compilado con soporte a pg_upgrade
El mar. 11, 2016 5:16 PM, "Alvaro Herrera" <alvhe...@2ndquadrant.com>
escribió:

> Hellmuth Vargas escribió:
>
> > Por lo tanto dado que contamos con una arquitectura maestro/esclavos
> para
> > backup en linea y balanceo de carga para los reportes (los informes se
> > generan a partir de la replicas), podría colocar uno de estos
> > servidores vitesse DB como una replica para mejorar el desempeño de los
> > informes. Pero trate de realizar una prueba y me encontré con esto:
> >
> > - En el instalador que disponen de prueba, no tiene el programa
> pg_upgrade.
>
> ¿Probaste a usar el pg_upgrade de la distribución estándar de Postgres
> con el pg_dump/pg_restore de Vitesse?  Debería funcionar.  Lo que podría
> fallar sería la copia de datos en tablas que tuvieran algún formato no
> estándar, si es que hay alguno, pero me parece que no.
>
> Hasta donde entiendo, Vitesse ofrece una implementación más rápida de
> ciertas operaciones, pero no destruye compatibilidad con el resto del
> sistema, así que el pg_upgrade debería funcionar.
>
> > - No funciona colocar los binarios de vitesse DB  y copiar la data de la
> > master con pg_basebackup o con el anterior método pg_start_backup/rsync,
>
> Hmm, los catálogos de Vitesse son distintos, así que es casi obvio que
> no funcione.
>
> > no se si al adquirir la licencia proporcionen el script o las
> herramientas
> > para realizar esto. Lastima que no dispongan de este avance de forma
> libre
> >  para al comunidad PostgreSQL...
>
> El modelo de negocios de Vitesse es precisamente ofrecer código más
> rápido a cambio de un precio mayor.  Regalar el código no les daría
> ningún beneficio.
>
> --
> Álvaro Herrerahttp://www.2ndQuadrant.com/
> PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
>

[pgsql-es-ayuda] test de Vitesse DB

[Hellmuth Vargas]

Hola lista


En el ultimo ejemplar del "This Week's PostgreSQL News (#147)" sale el
siguiente articulo:

Scan and aggregate a 81 GB table in 5 seconds!

Vitesse DB Enterprise Edition is PostgreSQL enhanced with builtin
multi-threading, LLVM JIT and compressed column store. Check out the TPC-H
100 numbers, and discover why PostgreSQL is ready for reporting and data
warehouse.
CK TAN#SPONSORED


Me di a la tarea de probarlo y efectivamente su desempeño en cuanto  las
sentencias SELECT es 3 o 4 veces mas veloz que la versión estándar de
PostgreSQL: Formule unas preguntas en el soporte  con las siguientes
repuestas:


Hi Hellmuth,

Thanks for your inquiries. On your questions:


On Wed, Mar 9, 2016 at 1:45 PM,  wrote:

> ID: 3030001
> Name: Hellmuth Ivan Vargas Saenz
> Email: hiv...@gmail.com
> Product: Vitesse DB
> Issue: Hello, the main quality of vitesse DB is the response time of the
> querys .. is possible to configure a standard PostgreSQL server as master
> and a slave DB server vitesse asynchronous replica to reports?.


1/ Yes. Vitesse DB can totally work as a slave server. it is 100%
compatible.


> second question: I can manter a master / slave architecture with
> asynchronous replication with DB vitesse,
>

2/ Yes. Any where that a PG instance would work, Vitesse DB can be slotted
in without any modifications.


> Third question; it has all the standard tools PostgreSQL?vacuum, pg_dump
> / restore, JDBC driver , etc etc.Thanks


 3/ Yes. 100% is 100% :-)

Cheers,
-cktan

Por lo tanto dado que contamos con una arquitectura maestro/esclavos  para
backup en linea y balanceo de carga para los reportes (los informes se
generan a partir de la replicas), podría colocar uno de estos
servidores vitesse DB como una replica para mejorar el desempeño de los
informes. Pero trate de realizar una prueba y me encontré con esto:

- En el instalador que disponen de prueba, no tiene el programa pg_upgrade.
- No funciona colocar los binarios de vitesse DB  y copiar la data de la
master con pg_basebackup o con el anterior método pg_start_backup/rsync,

La única manera para disponer de la informacion anterior en un
servidor  vitesse DB es por medio de dump/restore y por supuesto tendría
que disponerse todo el stack con este servidor

no se si al adquirir la licencia proporcionen el script o las herramientas
para realizar esto. Lastima que no dispongan de este avance de forma libre
 para al comunidad PostgreSQL...



Cordialmente,

Ing. Hellmuth I. Vargas S.
EnterpriseDB Certified PostgreSQL 9.3 Associate

[pgsql-es-ayuda]

[Hellmuth Vargas]

Hola lista


En el ultimo ejemplar del "This Week's PostgreSQL News (#147)" sale el
siguiente articulo:

Scan and aggregate a 81 GB table in 5 seconds!

Vitesse DB Enterprise Edition is PostgreSQL enhanced with builtin
multi-threading, LLVM JIT and compressed column store. Check out the TPC-H
100 numbers, and discover why PostgreSQL is ready for reporting and data
warehouse.
CK TAN#SPONSORED


Me di a la tarea de probarlo y efectivamente su desempeño en cuanto  las
sentencias SELECT es 3 o 4 veces mas veloz que la versión estándar de
PostgreSQL: Formule unas preguntas en el soporte  con las siguientes
repuestas:


Hi Hellmuth,

Thanks for your inquiries. On your questions:


On Wed, Mar 9, 2016 at 1:45 PM,  wrote:

> ID: 3030001
> Name: Hellmuth Ivan Vargas Saenz
> Email: hiv...@gmail.com
> Product: Vitesse DB
> Issue: Hello, the main quality of vitesse DB is the response time of the
> querys .. is possible to configure a standard PostgreSQL server as master
> and a slave DB server vitesse asynchronous replica to reports?.


1/ Yes. Vitesse DB can totally work as a slave server. it is 100%
compatible.


> second question: I can manter a master / slave architecture with
> asynchronous replication with DB vitesse,
>

2/ Yes. Any where that a PG instance would work, Vitesse DB can be slotted
in without any modifications.


> Third question; it has all the standard tools PostgreSQL?vacuum, pg_dump
> / restore, JDBC driver , etc etc.Thanks


 3/ Yes. 100% is 100% :-)

Cheers,
-cktan

Por lo tanto dado que contamos con una arquitectura maestro/esclavos  para
backup en linea y balanceo de carga para los reportes (los informes se
generan a partir de la replicas), podría colocar uno de estos
servidores vitesse DB como una replica para mejorar el desempeño de los
informes. Pero trate de realizar una prueba y me encontré con esto:

- En el instalador que disponen de prueba, no tiene el programa pg_upgrade.
- No funciona colocar los binarios de vitesse DB  y copiar la data de la
master con pg_basebackup o con el anterior método pg_start_backup/rsync,

La única manera para disponer de la informacion anterior en un
servidor  vitesse DB es por medio de dump/restore y por supuesto tendría
que disponerse todo el stack con este servidor

no se si al adquirir la licencia proporcionen el script o las herramientas
para realizar esto. Lastima que no dispongan de este avance de forma libre
 para al comunidad PostgreSQL...



Cordialmente,

Ing. Hellmuth I. Vargas S.
EnterpriseDB Certified PostgreSQL 9.3 Associate

Re: [pgsql-es-ayuda] Constraint Check de varios campos en varias combinaciones

[Hellmuth Vargas]

Hola Jorge

Se puede incluir cualquier expresión que retorne un boolean y que solo
dependan de los campos  de la propia tabla o variables globales (now() por
ejemplo).


El 25 de febrero de 2016, 15:45, Jorge Lobo Arteaga<jorgelo...@hotmail.com>
escribió:

> Mil gracias. Me funcionó perfecto.
>
>
> Como nota adicional; no sabía que se podían incluir estructuras de
> control.  Se pueden incluir otro tipo de código dentro del CHECK. ?
>
>
>
>
>
> ------
> *De:* Hellmuth Vargas <hiv...@gmail.com>
> *Enviado:* jueves, 25 de febrero de 2016 7:58 p. m.
> *Para:* Jorge Lobo Arteaga
> *Cc:* pgsql-es-ayuda@postgresql.org
> *Asunto:* Re: [pgsql-es-ayuda] Constraint Check de varios campos en
> varias combinaciones
>
> Hola Jorge
>
> Pruebe con esto:
>
>
> create table predio(
> tipo integer not null,
> nom varchar(40),
> apto char(6),
> constraint ck_tipo_predio_de_1_a_5 check(tipo >= 1 and tipo<=5),
> constraint ck_other check (case when tipo in (1,2) then  nom is null
> and apto is null
>   when tipo in (3) then nom is not null
>   when tipo in (4,5) then apto is not null and nom is not null end)
> );
>
> 2016-02-25 14:33 GMT-05:00 Jorge Lobo Arteaga <jorgelo...@hotmail.com>:
>
>> Buenas tardes,
>>
>>
>> Tengo una tabla así
>>
>>
>> create table predio(
>>
>> tipo integer not null,
>>
>> nom varchar(40),
>>
>> apto char(6),
>>
>> constraint ck_tipo_predio_de_1_a_5 check(tipo >= 1 and tipo<=5)
>>
>> );
>>
>>
>> 'nom' y 'apto' no son NOT NULL debido a que la obligatoriedad de dichos
>> campos dependen del valor del campo 'tipo',
>>
>> teniendo en cuenta las siguientes condiciones.
>>
>>
>> El campo 'tipo' almacena los tipos de predios así: 1-Casa, 2-Casa lote,
>> 3-Apartamento, 4-Edificio, 5-Conjunto cerrado.
>>
>> El campo 'nom' almacena el nombre del predio, solo si el tipo de predio
>> es 3, 4 o 5. Caso contrario será NULL.
>>
>> El campo 'apto' almacena el número de apartamento o vivienda, solo si el
>> tipo de predio es 4 o 5. Caso contrario será NULL.
>>
>> Los campos 'nom' y 'apto' serán NULL, solo si tipo de predio es 1 o 2.
>>
>>
>> No he podido hacer que las restricciones de tablas funcionen usando
>> CHECK.  He insistido bastante, pero creo que solo se va a poder
>>
>> usando TRIGGERS.
>>
>>
>> Gracias por su apoyo.
>>
>>
>>
>>
>>
>>
>>
>
>
> --
> Cordialmente,
>
> Ing. Hellmuth I. Vargas S.
> Esp. Telemática y Negocios por Internet
> Oracle Database 10g Administrator Certified Associate
> EnterpriseDB Certified PostgreSQL 9.3 Associate
>
>


-- 
Cordialmente,

Ing. Hellmuth I. Vargas S.
Esp. Telemática y Negocios por Internet
Oracle Database 10g Administrator Certified Associate
EnterpriseDB Certified PostgreSQL 9.3 Associate

Re: [pgsql-es-ayuda] Constraint Check de varios campos en varias combinaciones

[Hellmuth Vargas]

Hola Jorge

Pruebe con esto:


create table predio(
tipo integer not null,
nom varchar(40),
apto char(6),
constraint ck_tipo_predio_de_1_a_5 check(tipo >= 1 and tipo<=5),
constraint ck_other check (case when tipo in (1,2) then  nom is null
and apto is null
  when tipo in (3) then nom is not null
  when tipo in (4,5) then apto is not null and nom is not null end)
);

2016-02-25 14:33 GMT-05:00 Jorge Lobo Arteaga :

> Buenas tardes,
>
>
> Tengo una tabla así
>
>
> create table predio(
>
> tipo integer not null,
>
> nom varchar(40),
>
> apto char(6),
>
> constraint ck_tipo_predio_de_1_a_5 check(tipo >= 1 and tipo<=5)
>
> );
>
>
> 'nom' y 'apto' no son NOT NULL debido a que la obligatoriedad de dichos
> campos dependen del valor del campo 'tipo',
>
> teniendo en cuenta las siguientes condiciones.
>
>
> El campo 'tipo' almacena los tipos de predios así: 1-Casa, 2-Casa lote,
> 3-Apartamento, 4-Edificio, 5-Conjunto cerrado.
>
> El campo 'nom' almacena el nombre del predio, solo si el tipo de predio es
> 3, 4 o 5. Caso contrario será NULL.
>
> El campo 'apto' almacena el número de apartamento o vivienda, solo si el
> tipo de predio es 4 o 5. Caso contrario será NULL.
>
> Los campos 'nom' y 'apto' serán NULL, solo si tipo de predio es 1 o 2.
>
>
> No he podido hacer que las restricciones de tablas funcionen usando
> CHECK.  He insistido bastante, pero creo que solo se va a poder
>
> usando TRIGGERS.
>
>
> Gracias por su apoyo.
>
>
>
>
>
>
>


-- 
Cordialmente,

Ing. Hellmuth I. Vargas S.
Esp. Telemática y Negocios por Internet
Oracle Database 10g Administrator Certified Associate
EnterpriseDB Certified PostgreSQL 9.3 Associate

Re: [pgsql-es-ayuda] join super lento

[Hellmuth Vargas]

Hola Horario


Si, tenemos una tarea pendiente de ajustar la carga de la informacion
externa, actualmente  el servidor se encuentra en la versión 9.4 por lo
tanto UPSERT no esta disponible, vamos a trabajar en ese tema. Muchas
Gracias por sus comentarios y tiempo.


El 23 de febrero de 2016, 17:39, Horacio Miranda<hmira...@gmail.com>
escribió:

>
>
> On 2/24/2016 4:30 AM, Alvaro Herrera wrote:
>
>> Hellmuth Vargas escribió:
>>
>> Ejecute el EXPLAIN ANALYZE y lo termine a los 4 minutos sin resultados
>>>
>>
>> Cuando tengas tiempo (por ej. justo antes de irte de la oficina), deja
>> la consulta corriendo varias horas para tener un EXPLAIN ANALYZE.  No
>> sirve de nada que lo estés cortando a los 4 minutos, porque la
>> información que obtengas puede ser útil para poder encontrar la solución
>> al problema.
>>
>
> Hellmuth, el problema como te estoy diciendo son los datos...
>
> Mira este link https://wiki.postgresql.org/wiki/SQL_MERGE
>
> 1.0 ) puedes hacer un proceso de limpieza...
> 2.0 ) puedes hacer un merge ( Oracle insert/update ) en postgresql se
> llama UPSERT, Alvaro podría responder mejor a esta función que creo
> ayudaría a Hellmuth a tener un sistema más limpio (los datos que se
> insertan usando el web service o un acceso externo).
>
> Mantengo un sistema de GPS que me insertan los mismos datos en la noche (
> la única forma de no tener duplicados es con un merge ) y teniendo datos
> únicos se insertan 2.5M de registros diarios.
>
> Ahora lo que puedes hacer ( como tus v2 que son una copia de producción )
> es hacer el insert sacando los datos de producción por día y con un
> distinct. Algo como "insert into V2 (select distinct ...)"
>
> PS2: Oracle me crea una vista en el plan de ejecución ( con el uso de
> distinct ) el efecto es increíble de rápido. ( el SGA de Oracle es de 1.8G
> ) y la ram de la maquina virtual es de 8G 2CPU
>
>
> http://dba.stackexchange.com/questions/73448/what-is-this-view-being-used-in-my-query
>
> ** De hecho creo que tu consulta reestructurada es lo que Oracle esta
> haciendo ( Oracle reordena las consultas cuando hay un distinct ), solo te
> falto agregar el distinct en la primera consulta y en postgresql es más
> rápido que Oracle :D
>
> Adjunto el plan de ejecución de tu consulta :D  con mis datos.
>
>
>> QUERY PLAN
>>
>> ---
>>  HashAggregate  (cost=1864.15..1964.15 rows=1 width=894) (actual
>> time=120.230..120.254 rows=5 loops=1)
>>Group Key: t.descripcionmovimiento, t.fechamto, t.horamto, t.fechaact,
>> t.horaact, t.usuario, t.identificacionusuario, t.tipomovimientosusuario,
>> c.fecha, c.nombre, c.regionalath, c.regionaltdv, c.tiposolicitud, 1
>>->  Merge Left Join  (cost=532.61..1514.15 rows=1 width=894)
>> (actual time=44.693..104.844 rows=1 loops=1)
>>  Merge Cond: ((t.fechamto = c.fecha) AND (t.identificacionusuario
>> = c.identificacion))
>>  ->  Index Only Scan using idx_ath_tecnicosv2_comp on
>> ath_tecnicosv2 t  (cost=0.29..921.82 rows=1 width=522) (actual
>> time=0.036..15.375 rows=1 loops=1)
>>Index Cond: (fechamto >= '2016-02-18'::date)
>>Heap Fetches: 1
>>  ->  Sort  (cost=532.33..534.83 rows=1000 width=380) (actual
>> time=44.643..55.494 rows=8001 loops=1)
>>Sort Key: c.fecha, c.identificacion
>>Sort Method: quicksort  Memory: 25kB
>>->  HashAggregate  (cost=462.50..472.50 rows=1000
>> width=380) (actual time=44.607..44.615 rows=5 loops=1)
>>  Group Key: c.fecha, c.nombre, c.regionalath,
>> c.regionaltdv, c.tiposolicitud, c.identificacion
>>  ->  Seq Scan on ath_cajerosv2 c  (cost=0.00..312.50
>> rows=1 width=380) (actual time=0.022..22.432 rows=1 loops=1)
>>Filter: (fecha >= '2016-02-18'::date)
>>Rows Removed by Filter: 5000
>>  Planning time: 0.494 ms
>>  Execution time: 120.538 ms
>> (17 rows)
>>
>
>
> la maquina virtual postgresql es un gentoo con 22G ram y 4 CPU ( ambos con
> discos SSD ), tendre que leer por que oracle hace eso cuando hay un
> distinct y postgresql no ... eso me llamo la atención ( La verdad usar
> distinct lo evito, es indicativo d

Re: [pgsql-es-ayuda] join super lento

[Hellmuth Vargas]

de la misma:

SELECT pg_size_pretty(SUM(tamanos))
FROM (
  SELECT pg_column_size(row(b.*)) as tamanos
  FROM (
  select t.descripcionmovimiento, t.fechamto, t.horamto, t.fechaact,
t.horaact, t.usuario, t.identificacionusuario, t.tipomovimientosusuario,
c.fecha, c.nombre, c.regionalath, c.regionaltdv, c.tiposolicitud, 1 as cant
from public.ath_tecnicosv2 t
left join (select distinct c.fecha, c.nombre, c.regionalath, c.regionaltdv,
c.tiposolicitud,c.identificacion from public.ath_cajerosv2 as c where fecha
>= '20160218')  c on t.identificacionusuario=c.identificacion and
t.fechamto=c.fecha
where fecha >= '20160218' and fechamto >= '20160218'
) as b
) AS c;

 pg_size_pretty

*143 MB*
(1 row


Y el EXPLAIN ANALYZE

Nested Loop  (cost=285.61..6893.83 rows=2191 width=179) (actual
time=10.962..331.457 rows=712969 loops=1)
  ->  HashAggregate  (cost=285.53..289.16 rows=908 width=64) (actual
time=10.919..11.307 rows=683 loops=1)
->  Index Scan using idx_ath_cajerosv2_fecha on ath_cajerosv2 c
 (cost=0.08..258.30 rows=9076 width=64) (actual time=0.054..5.690 rows=9046
loops=1)
  Index Cond: ((fecha >= '2016-02-18'::date) AND (fecha >=
'2016-02-18'::date))
  ->  Index Scan using idx_ath_tecnicosv2_comp on ath_tecnicosv2 t
 (cost=0.09..7.25 rows=6 width=123) (actual time=0.008..0.270 rows=1044
loops=683)
Index Cond: ((identificacionusuario = c.identificacion) AND
(fechamto = c.fecha) AND (fechamto >= '2016-02-18'::date))
Total runtime: 360.616 ms


y la consulta sale  a los 1:45 minutos!!!

Mea culpa!! aveces con el afan de optimizar y ajustar no se analiza la
realidad de los datos y no me había percatado que habían tantos duplicados
en la tabla cajeros!! Les agradezco a todos sus comentarios y tiempo. Hoy
he aprendido un poco mas...






El 23 de febrero de 2016, 03:23, Horacio Miranda<hmira...@gmail.com>
escribió:

> Lo único que se me ocurre a esta altura es crear una vista materializada
> para tu consulta y que corra en la noche...
>
>
> Si quieres usar vistar mira este link.
>
>
> http://michael.otacoo.com/postgresql-2/postgres-9-4-feature-highlight-refresh-concurrently-a-materialized-view/
>
>
> On 2/23/2016 11:54 AM, Hellmuth Vargas wrote:
>
>> Hola Horacio
>>
>> El group by es porque originalmente había un distinct porque salen
>> registros duplicados ( son registros de trazas según me dicen)  por lo
>> tanto cambie el distinct por group by pues es más óptimo.  Igual lo
>> retire en un principio y tampoco obtuvo resultados.
>>
>> El feb. 22, 2016 5:45 PM, "Horacio Miranda" <hmira...@gmail.com
>> <mailto:hmira...@gmail.com>> escribió:
>>
>> Pregunta tonta
>>
>> Para que quieres hacer un group by ? cuando no hay funciones que
>> necesiten un group by ?
>>
>> Puedes correr la consulta sin el group by for favor.
>>
>> PS: ahora tengo tiempo para mirar esto y estoy viendo como crear
>> datos...
>>
>>


-- 
Cordialmente,

Ing. Hellmuth I. Vargas S.
Esp. Telemática y Negocios por Internet
Oracle Database 10g Administrator Certified Associate
EnterpriseDB Certified PostgreSQL 9.3 Associate

Re: [pgsql-es-ayuda] join super lento

[Hellmuth Vargas]

Hola Horacio

El group by es porque originalmente había un distinct porque salen
registros duplicados ( son registros de trazas según me dicen)  por lo
tanto cambie el distinct por group by pues es más óptimo.  Igual lo retire
en un principio y tampoco obtuvo resultados.
El feb. 22, 2016 5:45 PM, "Horacio Miranda"  escribió:

> Pregunta tonta
>
> Para que quieres hacer un group by ? cuando no hay funciones que necesiten
> un group by ?
>
> Puedes correr la consulta sin el group by for favor.
>
> PS: ahora tengo tiempo para mirar esto y estoy viendo como crear datos...
>

Re: [pgsql-es-ayuda] join super lento

[Hellmuth Vargas]

Hola Antony

Si es demasiado alto, lo estuve subiendo de a 255 MB cada vez, llegando
hasta este punto para verificar.. en ninguno de los casos mejoro.

El 22 de febrero de 2016, 14:39, Mario Soto Cordones<
marioa.soto.cordo...@gmail.com> escribió:

> Para colocar ese valor tan alto, debes considerar tu max_connections
>
>
>
> El valor que estás colocando es muy alto
>
>
>
>
>
> *De:* pgsql-es-ayuda-ow...@postgresql.org [mailto:
> pgsql-es-ayuda-ow...@postgresql.org] *En nombre de *Hellmuth Vargas
> *Enviado el:* lunes, 22 de febrero de 2016 16:35
> *Para:* Eduardo Morras <emorr...@yahoo.es>
> *CC:* Lista Postgres ES <pgsql-es-ayuda@postgresql.org>
> *Asunto:* Re: [pgsql-es-ayuda] join super lento
>
>
>
>
>
>
>
> Hola Antony
>
>
>
> Pues, restaure indices y  lleve el work_mem  hasta 4096 MB (la tercera
> parte de la RAM del servidor) y pasaron 4 minutos y nada.
>
>
>
> set local work_mem='4096 MB'
>
>
>
>
>
> select t.descripcionmovimiento, t.fechamto, t.horamto, t.fechaact,
> t.horaact, t.usuario, t.identificacionusuario, t.tipomovimientosusuario,
> c.fecha, c.nombre, c.regionalath, c.regionaltdv, c.tiposolicitud, 1 as cant
>
> from public.ath_tecnicosv2 t
>
> left join public.ath_cajerosv2 c on
> t.identificacionusuario=c.identificacion and t.fechamto=c.fecha
>
> where fecha >= '20160218' and fechamto >= '20160218'
>
> group by  t.descripcionmovimiento, t.fechamto, t.horamto, t.fechaact,
> t.horaact, t.usuario, t.identificacionusuario, t.tipomovimientosusuario,
> c.fecha, c.nombre, c.regionalath, c.regionaltdv, c.tiposolicitud,1
>
>
>
>
>
>
>
>
>
> 
>
> Por otro lado Eduardo,
>
>
>
> Elimine todos los indices y cree los que sugiere (aunque el ExPLAIN me
> indica  crear indices sobre las fechas antes que  otros  atributos):
>
>
>
> CREATE INDEX idx_ath_cajerosv2_comp
>
>   ON ath_cajerosv2
>
>   USING btree
>
>   (identificacion, fecha);
>
>
>
>
>
> CREATE INDEX idx_ath_tecnicosv2_comp
>
>   ON ath_tecnicosv2
>
>   USING btree
>
>   (identificacionusuario, fechamto);
>
>
>
>
>
> CREATE INDEX idx_ath_tecnicosv2_comp2
>
>   ON ath_tecnicosv2
>
>   USING btree
>
>   (descripcionmovimiento COLLATE pg_catalog."default", fechamto, horamto
> COLLATE pg_catalog."default", fechaact COLLATE pg_catalog."default",
> horaact COLLATE pg_catalog."default", usuario COLLATE pg_catalog."default",
> identificacionusuario, tipomovimientosusuario COLLATE pg_catalog."default");
>
>
>
>
>
>
>
> Eso genero este plan de ejecución:
>
>
>
>
>
> Group  (cost=96536.23..101779.31 rows=749012 width=179)
>
>   ->  Sort  (cost=96536.23..96910.74 rows=749012 width=179)
>
> Sort Key: t.descripcionmovimiento, t.fechamto, t.horamto,
> t.fechaact, t.horaact, t.usuario, t.identificacionusuario,
> t.tipomovimientosusuario, c.fecha, c.nombre, c.regionalath, c.regionaltdv,
> c.tiposolicitud
>
> ->  Nested Loop  (cost=0.09..42932.64 rows=749012 width=179)
>
>   ->  Seq Scan on ath_cajerosv2 c  (cost=0.00..2952.22
> rows=9072 width=64)
>
> Filter: (fecha >= '2016-02-18'::date)
>
>   ->  Index Scan using idx_ath_tecnicosv2_comp on
> ath_tecnicosv2 t  (cost=0.09..4.38 rows=6 width=123)
>
> Index Cond: ((identificacionusuario =
> c.identificacion) AND (fechamto = c.fecha) AND (fechamto >=
> '2016-02-18'::date))
>
>
>
>
>
>
>
> Ejecute el EXPLAIN ANALYZE, espere 3 minutos y nada ...
>
>
>
> En cuanto al PRIMARY KEY tengo entendido que un indice unique sobre el
> campo ID  brinda los mismos  resultados y que no tendría importancia la
> posición de la columna respecto  a las demás al menos en PostgreSQL (si me
> equivoco me corrigen por favor), Incluso las columnas ID yo las agregue
> 'artificialmente' pues originalmente no las tenia las tablas, le agregue
> estos campos con el propósito de probar los JOIN solo con ID.
>
>
>
>
>
> El 22 de febrero de 2016, 13:47, Eduardo Morras<emorr...@yahoo.es>
> escribió:
>
> On Mon, 22 Feb 2016 09:55:21 -0500
> Hellmuth Vargas <hiv...@gmail.com> wrote:
>
> > Hola Lista
> > Les tengo el siguiente desafio pues no he podido dar con el tema,
> > tengo dos tablas
> >
> > CREATE TABLE ath_tecnicosv2
> > (
> >   descripcionmovimiento character varying(160),
> >   fechamto date,
> >   horamto character varying(8),
> >   fechaact character varying(8),
> >   horaact char

Re: [pgsql-es-ayuda] join super lento

[Hellmuth Vargas]

Hola Antony

Pues, restaure indices y  lleve el work_mem  hasta 4096 MB (la tercera
parte de la RAM del servidor) y pasaron 4 minutos y nada.

set local work_mem='4096 MB'


select t.descripcionmovimiento, t.fechamto, t.horamto, t.fechaact,
t.horaact, t.usuario, t.identificacionusuario, t.tipomovimientosusuario,
c.fecha, c.nombre, c.regionalath, c.regionaltdv, c.tiposolicitud, 1 as cant
from public.ath_tecnicosv2 t
left join public.ath_cajerosv2 c on
t.identificacionusuario=c.identificacion and t.fechamto=c.fecha
where fecha >= '20160218' and fechamto >= '20160218'
group by  t.descripcionmovimiento, t.fechamto, t.horamto, t.fechaact,
t.horaact, t.usuario, t.identificacionusuario, t.tipomovimientosusuario,
c.fecha, c.nombre, c.regionalath, c.regionaltdv, c.tiposolicitud,1





Por otro lado Eduardo,

Elimine todos los indices y cree los que sugiere (aunque el ExPLAIN me
indica  crear indices sobre las fechas antes que  otros  atributos):

CREATE INDEX idx_ath_cajerosv2_comp
  ON ath_cajerosv2
  USING btree
  (identificacion, fecha);


CREATE INDEX idx_ath_tecnicosv2_comp
  ON ath_tecnicosv2
  USING btree
  (identificacionusuario, fechamto);


CREATE INDEX idx_ath_tecnicosv2_comp2
  ON ath_tecnicosv2
  USING btree
  (descripcionmovimiento COLLATE pg_catalog."default", fechamto, horamto
COLLATE pg_catalog."default", fechaact COLLATE pg_catalog."default",
horaact COLLATE pg_catalog."default", usuario COLLATE pg_catalog."default",
identificacionusuario, tipomovimientosusuario COLLATE pg_catalog."default");



Eso genero este plan de ejecución:


Group  (cost=96536.23..101779.31 rows=749012 width=179)
  ->  Sort  (cost=96536.23..96910.74 rows=749012 width=179)
Sort Key: t.descripcionmovimiento, t.fechamto, t.horamto,
t.fechaact, t.horaact, t.usuario, t.identificacionusuario,
t.tipomovimientosusuario, c.fecha, c.nombre, c.regionalath, c.regionaltdv,
c.tiposolicitud
->  Nested Loop  (cost=0.09..42932.64 rows=749012 width=179)
  ->  Seq Scan on ath_cajerosv2 c  (cost=0.00..2952.22
rows=9072 width=64)
Filter: (fecha >= '2016-02-18'::date)
  ->  Index Scan using idx_ath_tecnicosv2_comp on
ath_tecnicosv2 t  (cost=0.09..4.38 rows=6 width=123)
Index Cond: ((identificacionusuario = c.identificacion)
AND (fechamto = c.fecha) AND (fechamto >= '2016-02-18'::date))



Ejecute el EXPLAIN ANALYZE, espere 3 minutos y nada ...

En cuanto al PRIMARY KEY tengo entendido que un indice unique sobre el
campo ID  brinda los mismos  resultados y que no tendría importancia la
posición de la columna respecto  a las demás al menos en PostgreSQL (si me
equivoco me corrigen por favor), Incluso las columnas ID yo las agregue
'artificialmente' pues originalmente no las tenia las tablas, le agregue
estos campos con el propósito de probar los JOIN solo con ID.


El 22 de febrero de 2016, 13:47, Eduardo Morras<emorr...@yahoo.es> escribió:

> On Mon, 22 Feb 2016 09:55:21 -0500
> Hellmuth Vargas <hiv...@gmail.com> wrote:
>
> > Hola Lista
> > Les tengo el siguiente desafio pues no he podido dar con el tema,
> > tengo dos tablas
> >
> > CREATE TABLE ath_tecnicosv2
> > (
> >   descripcionmovimiento character varying(160),
> >   fechamto date,
> >   horamto character varying(8),
> >   fechaact character varying(8),
> >   horaact character varying(8),
> >   usuario character varying(50),
> >   identificacionusuario bigint,
> >   tipomovimientosusuario character varying(25),
> >   id bigserial NOT NULL
> > )
> > WITH (
> >   OIDS=FALSE
> > );
> >
> > -- tamaño: 1639200 registros
> >
> > CREATE UNIQUE INDEX idx_u_ath_tecnicosv2_id
> >   ON ath_tecnicosv2
> >   USING btree
> >   (id);
> >
> > CREATE INDEX idx_ath_tecnicosv2_comp
> >   ON ath_tecnicosv2
> >   USING btree
> >   (fechamto, identificacionusuario, descripcionmovimiento COLLATE
> > pg_catalog."default", horamto COLLATE pg_catalog."default", fechaact
> > COLLATE pg_catalog."default", horaact COLLATE pg_catalog."default",
> > usuario COLLATE pg_catalog."default", tipomovimientosusuario COLLATE
> > pg_catalog."default");
> >
> > CREATE INDEX idx_ath_tecnicosv2_fecha2
> >   ON public.ath_tecnicosv2
> >   USING btree
> >   (fechamto asc, identificacionusuario asc,id);
> >
> >
> > CREATE TABLE ath_cajerosv2
> > (
> >   fecha date,
> >   nombre character varying(60),
> >   regionalath character varying(24),
> >   regionaltdv character varying(54),
> >   tiposolicitud character varying(10),
> >   id_usuario character varying(4),
> >   identificaci

Re: [pgsql-es-ayuda] Funcion con RETURNS SETOF record

[Hellmuth Vargas]

Hola Lista

La reescribí asi:

CREATE OR REPLACE FUNCTION public.f_xconsulta(character varying) RETURNS
SETOF record AS
$BODY$
DECLARE
codigo ALIAS FOR $1;
_registro record;

BEGIN
RETURN  QUERY SELECT COD_PER,
NOM_PER
FROM XPERSONA
WHERE COD_PER = codigo;

END;

$BODY$
LANGUAGE 'plpgsql' VOLATILE
COST 100

ROWS 1000;


Para ejecutar:

SELECT * from f_xconsulta('01') as (COD_PER CHAR(2),NOM_PER VARCHAR(20));






2016-01-19 10:46 GMT-05:00 Alberto Cuevas :

> Hola estoy haciendo unas pruebas para usar una función con RETURNS SETOF
> record, con los siguiente:
>
> CREATE TABLE XPERSONA (
> COD_PER CHAR(2),
> NOM_PER VARCHAR(20));
>
> INSERT INTO XPERSONA VALUES ('01', 'ALBERTO');
> INSERT INTO XPERSONA VALUES ('02', 'CARLOS');
> INSERT INTO XPERSONA VALUES ('03', 'JUAN');
>
> CREATE OR REPLACE FUNCTION public.f_xconsulta(character varying) RETURNS
> SETOF record AS
> $BODY$
> DECLARE
> codigo ALIAS FOR $1;
> _registro record;
>
> BEGIN
>
> FOR _registro IN
> SELECT COD_PER,
> NOM_PER
> FROM XPERSONA
> WHERE COD_PER = codigo
> loop
>  return next _registro;
>
> END LOOP;
>
> RETURN;
> END;
>
> $BODY$
> LANGUAGE 'plpgsql' VOLATILE
> COST 100
>
> ROWS 1000;
>
>
> Pero al ejecutar:
>
> SELECT f_xconsulta('01');
>
> Me muestra el siguiente mensaje en PGAdmin:
>
> ERROR: se llamó una función que retorna un conjunto en un contexto que no
> puede aceptarlo CONTEXT: función PL/pgSQL f_xconsulta(character varying) en
> la línea 17 en RETURN NEXT
>
> ** Error **
>
> ERROR: se llamó una función que retorna un conjunto en un contexto que no
> puede aceptarlo SQL state: 0A000 Context: función PL/pgSQL
> f_xconsulta(character varying) en la línea 17 en RETURN NEXT
>
> Me podrian dar una mano por favor. Uso Postgresql 9.4.5.
>



-- 
Cordialmente,

Ing. Hellmuth I. Vargas S.
Esp. Telemática y Negocios por Internet
Oracle Database 10g Administrator Certified Associate
EnterpriseDB Certified PostgreSQL 9.3 Associate

Re: [pgsql-es-ayuda] Base de Datos Corrupta

[Hellmuth Vargas]

Hola

Verifique también si tienes tablespace definidos y por lo tanto puede tener
archivos de la base en otras carpetas aparte de la de data lo que
explicaría que no se encontrará archivos de algunas tablas
El dic. 28, 2015 8:18 PM, "Horacio Miranda"  escribió:

> Si copiaste la carpeta debiera estar OK
>
> Los permisos estan correctos ? todos los archivos pertenecen a postgres ?
>
> Por lo que dices no tienes politica de respaldos ( implementa una ).
>
>
>
> On 12/29/2015 7:49 AM, Henry Interiano wrote:
>
>> El primer problema fue que la computadora donde estaba la base de datos
>> no arrancaba, logre a sacar la carpeta DATA, pasarla a otra instalación
>> con la misma versión, la base de datos se inicia correctamente. pero a
>> la hora hacer  "select"  a cualquier tabla devuelve el error que falta
>> el archivo.
>>
>> Gracias
>>
>> Henry Interiano
>>
>>
>> El 28 de diciembre de 2015, 12:36, Alvaro
>> Herrera>
>> escribió:
>>
>> Henry Interiano escribió:
>> > Gracias por responder,
>> >
>> > La base de datos la logre a recuperar pero a la hora de hacer
>> cualquier
>> > consulta, respaldo o ver las tablas en PgAdmin me devuelve que
>> falta tal
>> > archivo, revise los archivos y si esta el archivo vm_11838 y
>> fsm_11838.
>> >
>> > pero cuando hago una consulta "select * from pg_tables" aparacen
>> todas las
>> > tablas.
>>
>> OK.  Veo que comentaste varias cosas que ya habías dicho y unas pocas
>> que no habías dicho antes, pero no respondiste ninguna de mis
>> preguntas,
>> y tampoco hiciste tú ninguna pregunta ni pediste ayuda para nada
>> específico.
>>
>> Feliz fin de año.
>>
>> --
>> Álvaro Herrera http://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 replica 9.4 con slot

[Hellmuth Vargas]

Hola Martin

Muchas gracias por responder, verifique la replica y no tiene configurados
slot:

postgres=# select * from pg_replication_slots
postgres-# ;
 slot_name | plugin | slot_type | datoid | database | active | xmin |
catalog_xm
in | restart_lsn
---++---++--++--+---
---+-
(0 rows)


postgres=# select * from pg_stat_replication;
 pid | usesysid | usename | application_name | client_addr |
client_hostname | c
lient_port | backend_start | backend_xmin | state | sent_location |
write_locati
on | flush_location | replay_location | sync_priority | sync_state
-+--+-+--+-+-+--
---+---+--+---+---+-
---++-+---+
(0 rows)


mmm por el momento voy a desactivar los slot y continuare con archive
y wal_keep_segments


El 16 de diciembre de 2015, 08:15, Martín Marqués<martin.marq...@gmail.com>
escribió:

> Buenas,
>
> El día 9 de diciembre de 2015, 13:57, Hellmuth Vargas
> <hiv...@gmail.com> escribió:
> >
> >
> > master:
> >
> > [postgres@bd-1 data]# du -h pg_xlog/
> > 4,0Kpg_xlog/archive_status
> > 1,8Gpg_xlog/
> >
> >
> > replica retrasada sin motivo:
> >
> > bash-4.1$ du -h pg_xlog
> > 512Kpg_xlog/archive_status
> > 137Gpg_xlog
>
> Revisa el archive_status, y si no tenes algun slot en el standy.
>
> --
> Martín Marqués
> select 'martin.marques' || '@' || 'gmail.com'
> DBA, Programador, Administrador
>



-- 
Cordialmente,

Ing. Hellmuth I. Vargas S.
Esp. Telemática y Negocios por Internet
Oracle Database 10g Administrator Certified Associate
EnterpriseDB Certified PostgreSQL 9.3 Associate

[pgsql-es-ayuda] problemas replica 9.4 con slot

[Hellmuth Vargas]

Hola Lista


tengo una base de datos PostgreSQL 9,.4 con dos replicas con replication
slot, de forma aleatoria cada cierto tiempo las replicas se quedan
retrasadas  en la aplicación de los WAL sin explicación alguna, estas
replicas  solo se emplean de backup en linea, no se usan para realizar
consultas. para que vuelvan a aplicar los WAL  me ha tocado reinicarlas, es
la única forma que vuelven a funcionar y lo mas raro es que  la carpeta de
pg_xlog es enorme guardando archivos WAL,   con respecto a la master por lo
tanto si tiene los WAL disponibles y solo los acumula...en los logs tanto
de la master como de las replicas no sale nada.


master:

[postgres@bd-1 data]# du -h pg_xlog/
4,0Kpg_xlog/archive_status
1,8Gpg_xlog/


replica retrasada sin motivo:

bash-4.1$ du -h pg_xlog
512Kpg_xlog/archive_status
137Gpg_xlog

 ---

postgres=# select * from pg_stat_replication;
  pid  | usesysid | usename  | application_name |  client_addr  |
client_hostname | client_port | backend_start |
backend_xmin |   state   | sent_location | write_location | fl
ush_location | replay_location | sync_priority | sync_state
---+--+--+--+---+-+-+---+--+---+---++---
-+-+---+
  3875 |   10 | ureplication | walreceiver  | 192.168.XX.XX |
  |   56951 | 2015-12-09 11:38:46.646049-05 |  |
streaming | 2E/BF69C0D0   | 2E/BF69C0D0| 2E
/BF69C0D0| 2E/BF69C0D0 | 0 | async

--- la retrasada:
  4169 |   10 | ureplication | walreceiver  | 192.168.XX.XY|
  |   45781 | 2015-12-09 11:41:56.906862-05 |
 | streaming   | 2E/BBD8   | 2E/BBD2| 2E
/BBD2| 2E/BBCFF2D8 | 0 | async


-- 
Cordialmente,

Ing. Hellmuth I. Vargas S.

Re: [pgsql-es-ayuda] PITR Point in Time Recovery en linea administrado

[Hellmuth Vargas]

Hola lista..  Y no sobra agregar que es justo que con el Ultimo tipo de
empresas, con las cuales más retos y aprendizaje se obtiene..  Todos los
días nos sorprenden con algo nuevo...   :-)
El nov. 21, 2015 5:08 PM, "Hellmuth Vargas" <hiv...@gmail.com> escribió:

> Hola Alvaro y lista
>
> Mucha gracias por los comentarios,  yo  estoy completamente de acuerdo con
> ustedes sobre reforzar y formalizar un entorno de desarrollo pleno que
> aísle la base de producción de las manos inquietas de desarrollo y así lo
> tenemos en varias organizaciones, pero asi mismo también doy soporte a
> varios empresas pequeñas que el área de "desarrollo, sistemas e
> infraestructura" se reduce un ingeniero todero con un servidor donde tiene
> instalado toda su plataforma y ahí hace todo y cuanod digo todo es todo!!
> Con esfuerzo he logrado al menos implementarles replicación y backups
> diarios para contar al menos con un backup en linea en un equipo aparte
> (muchas veces en un pc) y son las condiciones donde igual se debe brindar
> el soporte y minimizar  los riesgos de  perdida de información.
>
>
>
>
> El nov. 21, 2015 2:51 PM, "Alvaro Herrera" <alvhe...@2ndquadrant.com>
> escribió:
>
>> Hellmuth Vargas escribió:
>>
>> > - Aplicación de cambios hasta un timestamp defnido
>> > - Aplicación de WAL interactivamente, algo como aplique el siguiente WAL
>> > para que por tanteo se pueda llegar a los datos mas próximos antes de la
>> > calamidad
>>
>> Con un restore_command suficientemente complicado podrías hacerlo.  Por
>> ejemplo podrías hacer uno que consdere un archivo "trigger", que hace
>> que el restore_command entre en modo "uno a uno" (digamos
>> /tmp/modo_1a1); en este modo, en vez de retornar inmediatamente con el
>> archivo que el servidor le pide, el restore_command se pondría a dormir
>> hasta que apareciera un archivo trigger distinto (digamos
>> /tmp/continuar_restore).  Cuando aparece, deja de dormir, elimina
>> /tmp/continuar_restore y envía el archivo.  (Es importante eliminar el
>> archivo, para que la creación de ese archivo sólo autorice un único
>> segmento WAL a restaurar).
>>
>> Eso te provee la interactividad.  Cuando elimines el /tmp/modo_1a1
>> entonces el restore_command se comporta normalmente, para evitar
>> apilamientos de archivos WAL cuando no necesitas esta funcionalidad.
>>
>> Para aplicar hasta un timestamp determinado, podrías hacer que tu
>> restore_command verifique existencia de otro archivo trigger.  Si
>> existe, lo lee y en él encuentra un recovery_target, y lo graba en el
>> recovery.conf, luego da un reload que si mal no recuerdo debería ser
>> suficiente para que el recovery no continúe indefinidamente sino que se
>> detenga cuando llegue al punto indicado.
>>
>> Esa es la ventaja de que el restore_command y archive_command sean
>> programas arbitrarios que tú escribes: puedes hacer lo que se te ocurra,
>> siempre y cuando tengas la imaginación suficiente.
>>
>> Ahora, estoy totalmente de acuerdo con César Erices: si tu problema es
>> que los DBAs se mandan cagadas por estar operando en la BD de producción
>> con exceso de alcohol en sangre, lo que deberías hacer en vez de perder
>> tiempo en esto es mejorar el entorno para que tengan donde jugar.
>>
>> --
>> Álvaro Herrerahttp://www.2ndQuadrant.com/
>> PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
>>
>

Re: [pgsql-es-ayuda] PITR Point in Time Recovery en linea administrado

[Hellmuth Vargas]

Hola Alvaro y lista

Mucha gracias por los comentarios,  yo  estoy completamente de acuerdo con
ustedes sobre reforzar y formalizar un entorno de desarrollo pleno que
aísle la base de producción de las manos inquietas de desarrollo y así lo
tenemos en varias organizaciones, pero asi mismo también doy soporte a
varios empresas pequeñas que el área de "desarrollo, sistemas e
infraestructura" se reduce un ingeniero todero con un servidor donde tiene
instalado toda su plataforma y ahí hace todo y cuanod digo todo es todo!!
Con esfuerzo he logrado al menos implementarles replicación y backups
diarios para contar al menos con un backup en linea en un equipo aparte
(muchas veces en un pc) y son las condiciones donde igual se debe brindar
el soporte y minimizar  los riesgos de  perdida de información.




El nov. 21, 2015 2:51 PM, "Alvaro Herrera" <alvhe...@2ndquadrant.com>
escribió:

> Hellmuth Vargas escribió:
>
> > - Aplicación de cambios hasta un timestamp defnido
> > - Aplicación de WAL interactivamente, algo como aplique el siguiente WAL
> > para que por tanteo se pueda llegar a los datos mas próximos antes de la
> > calamidad
>
> Con un restore_command suficientemente complicado podrías hacerlo.  Por
> ejemplo podrías hacer uno que consdere un archivo "trigger", que hace
> que el restore_command entre en modo "uno a uno" (digamos
> /tmp/modo_1a1); en este modo, en vez de retornar inmediatamente con el
> archivo que el servidor le pide, el restore_command se pondría a dormir
> hasta que apareciera un archivo trigger distinto (digamos
> /tmp/continuar_restore).  Cuando aparece, deja de dormir, elimina
> /tmp/continuar_restore y envía el archivo.  (Es importante eliminar el
> archivo, para que la creación de ese archivo sólo autorice un único
> segmento WAL a restaurar).
>
> Eso te provee la interactividad.  Cuando elimines el /tmp/modo_1a1
> entonces el restore_command se comporta normalmente, para evitar
> apilamientos de archivos WAL cuando no necesitas esta funcionalidad.
>
> Para aplicar hasta un timestamp determinado, podrías hacer que tu
> restore_command verifique existencia de otro archivo trigger.  Si
> existe, lo lee y en él encuentra un recovery_target, y lo graba en el
> recovery.conf, luego da un reload que si mal no recuerdo debería ser
> suficiente para que el recovery no continúe indefinidamente sino que se
> detenga cuando llegue al punto indicado.
>
> Esa es la ventaja de que el restore_command y archive_command sean
> programas arbitrarios que tú escribes: puedes hacer lo que se te ocurra,
> siempre y cuando tengas la imaginación suficiente.
>
> Ahora, estoy totalmente de acuerdo con César Erices: si tu problema es
> que los DBAs se mandan cagadas por estar operando en la BD de producción
> con exceso de alcohol en sangre, lo que deberías hacer en vez de perder
> tiempo en esto es mejorar el entorno para que tengan donde jugar.
>
> --
> Álvaro Herrerahttp://www.2ndQuadrant.com/
> PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
>

[pgsql-es-ayuda] PITR Point in Time Recovery en linea administrado

[Hellmuth Vargas]

Buenos dias Lista


Dado que  en algunas oportunidades (mas de las que quisiera) se borran
datos de tablas,o incluso las tablas mismas, se actualizan con datos
errores, etc etc, etc (otro tema es que entren usuario con privilegios a
hacer estas calamidades... ) para subsanar esto hay que restaurar backups y
con los WAL archivados restaurar los datos alterados, esto toma tiempo, mas
cuando las bases son grandes y mas cuando no se sabe exactamente la hora
del suceso; para la versión 9.4  existe la posibilidad de mantener una
replica retasada un X tiempo (
http://www.depesz.com/2013/12/20/waiting-for-9-4-allow-time-delayed-standbys-and-recovery/)
que ayuda bastante, pues es una base EN LINEA  con la foto de nuestra base
de hace X tiempo, mas si el cambio fue antes de este tiempo, ni modos...
Entonces la pregunta es:

Que posibilidades hay de mantener una replica en linea retrasada X tiempo
(casi una semana, por ejemplo) pero que se pudiera administrar la
aplicación de los WAL de forma manual, para permitir  operaciones
como  (todas  ojala dentro de una transaccion  para poder devolver el
cambio en el caso que uno se 'pasara' de la hora del suceso):


- Aplicación de cambios hasta un timestamp defnido
- Aplicación de WAL interactivamente, algo como aplique el siguiente WAL
para que por tanteo se pueda llegar a los datos mas próximos antes de la
calamidad

Y con todas las bondades de las replicas en linea. Muchas gracias Lista y
quedo atento a sus comentarios.







-- 
Cordialmente,

Ing. Hellmuth I. Vargas S.
Esp. Telemática y Negocios por Internet
Oracle Database 10g Administrator Certified Associate
EnterpriseDB Certified PostgreSQL 9.3 Associate

Re: [pgsql-es-ayuda] PITR Point in Time Recovery en linea administrado

[Hellmuth Vargas]

Hola cesar

Gracias por la respuesta, pero esas soluciones basadas en triggers
 penalizan mucho el rendimiento al menos en mi caso,tenemos  una base de
call center y otra de  registros GPS  de muchas operaciones por segundo
concurrentes. Una replica retrasada si funciona pues si un  desarrollador
por equivocación  corre una sentencia DML por error (un UPDATE sin WHERE
por ejemplo y a quien no le halla pasado que tire la primera piedra) y si
avisa rápidamente se puede rescatar los datos de la replica retrasada. Lo
que consulto es si puede contar con una replica retrasada donde los cambios
se puedan aplicar  de forma manual como lo expuse en el anterior correo.



El 20 de noviembre de 2015, 10:21 a. m., Cesar Erices<caeri...@gmail.com>
escribió:

> Estimado, buenas tardes.
>
> No se si entendi bien tu consulta, pero cuando hablas de borar datos te
> refieres a que por sistema se modifican o elimina información? de ser sí,
> creo que lo que solicitas (Replica) no te serviria, porque habitualmente
> las replicas mantienen la misma información que las originales y si
> eliminas un dato en X tiempo se te borrara en la replica y no te sirvira de
> mucho. Para esto te sugiero generar unas tablas de auditorias (replicas
> exactas de las tablas originales) que registren de manera interna (es decir
> por medio de triger) todos los cambios que se han realizado y a estas
> tablas generar un procedimiento para mantener la información de un X tiempo.
>
> Espero haber sido claro cualquier consulta me avisas.
>
> El 20 de noviembre de 2015, 11:45, Hellmuth Vargas <hiv...@gmail.com>
> escribió:
>
>> Buenos dias Lista
>>
>>
>> Dado que  en algunas oportunidades (mas de las que quisiera) se borran
>> datos de tablas,o incluso las tablas mismas, se actualizan con datos
>> errores, etc etc, etc (otro tema es que entren usuario con privilegios a
>> hacer estas calamidades... ) para subsanar esto hay que restaurar backups y
>> con los WAL archivados restaurar los datos alterados, esto toma tiempo, mas
>> cuando las bases son grandes y mas cuando no se sabe exactamente la hora
>> del suceso; para la versión 9.4  existe la posibilidad de mantener una
>> replica retasada un X tiempo (
>> http://www.depesz.com/2013/12/20/waiting-for-9-4-allow-time-delayed-standbys-and-recovery/)
>> que ayuda bastante, pues es una base EN LINEA  con la foto de nuestra base
>> de hace X tiempo, mas si el cambio fue antes de este tiempo, ni modos...
>> Entonces la pregunta es:
>>
>> Que posibilidades hay de mantener una replica en linea retrasada X tiempo
>> (casi una semana, por ejemplo) pero que se pudiera administrar la
>> aplicación de los WAL de forma manual, para permitir  operaciones
>> como  (todas  ojala dentro de una transaccion  para poder devolver el
>> cambio en el caso que uno se 'pasara' de la hora del suceso):
>>
>>
>> - Aplicación de cambios hasta un timestamp defnido
>> - Aplicación de WAL interactivamente, algo como aplique el siguiente WAL
>> para que por tanteo se pueda llegar a los datos mas próximos antes de la
>> calamidad
>>
>> Y con todas las bondades de las replicas en linea. Muchas gracias Lista y
>> quedo atento a sus comentarios.
>>
>>
>>
>>
>>
>>
>>
>> --
>> Cordialmente,
>>
>> Ing. Hellmuth I. Vargas S.
>> Esp. Telemática y Negocios por Internet
>> Oracle Database 10g Administrator Certified Associate
>> EnterpriseDB Certified PostgreSQL 9.3 Associate
>>
>>
>
>
> --
> Sin más que decir se despide de Usted, muy atentamente
>
> Cesar Erices Vergara
> Ingeniero en Gestión Informática
> Analista de Sistema
> Especialista en ISO 27001 e ITIL
>
> Cuenta Twitter: @caerices
>
> Santiago - Chile
>



-- 
Cordialmente,

Ing. Hellmuth I. Vargas S.
Esp. Telemática y Negocios por Internet
Oracle Database 10g Administrator Certified Associate
EnterpriseDB Certified PostgreSQL 9.3 Associate

Re: [pgsql-es-ayuda] PITR Point in Time Recovery en linea administrado

[Hellmuth Vargas]

Hola Horacio Muchas gracias por el comentario

La inquietud surge porque estuve leyendo algo similar en Oracle

https://moisesespinosa.wordpress.com/2011/09/19/flashback-i-introduccion/

 y dado que PostgreSQL implementa una replica retrasada pensé ..."y porque
no tener la posibilidad de  ir aplicando los cambios paso a paso hasta
lograr  la instantánea de los datos justo antes de que se hubiesen
borrado." en un caso hipotético que seria algo mas inmediato, expedito que
hacerlo por PITR



El 20 de noviembre de 2015, 2:41 p. m., Horacio Miranda<hmira...@gmail.com>
escribió:

> Hola, para tu problema ( ignoro si esto es util ), en un cliente ( Oracle
> ) teniamos el mismo problema, la forma de solucionarlo fue implemetnar
> Oracle Stream con WTL ( convirtiendo todos los update, delete en insert )
> para poder volver atras sin recuperar, la base de datos era de unos 10
> Teras eso si.
>
> Ignoro si en postgresql existe una forma de replicar y modificar lo que
> llega a la replica ( cosa de poder volver atras las transacciones ).
>
> Si no existe sería un feature que valdría la pena trabajar y hacer. :D
>
>
> On 11/21/2015 3:45 AM, Hellmuth Vargas wrote:
>
>> Buenos dias Lista
>>
>>
>> Dado que  en algunas oportunidades (mas de las que quisiera) se borran
>> datos de tablas,o incluso las tablas mismas, se actualizan con datos
>> errores, etc etc, etc (otro tema es que entren usuario con privilegios a
>> hacer estas calamidades... ) para subsanar esto hay que restaurar
>> backups y con los WAL archivados restaurar los datos alterados, esto
>> toma tiempo, mas cuando las bases son grandes y mas cuando no se sabe
>> exactamente la hora del suceso; para la versión 9.4  existe la
>> posibilidad de mantener una replica retasada un X tiempo
>> (
>> http://www.depesz.com/2013/12/20/waiting-for-9-4-allow-time-delayed-standbys-and-recovery/
>> )
>> que ayuda bastante, pues es una base EN LINEA  con la foto de nuestra
>> base de hace X tiempo, mas si el cambio fue antes de este tiempo, ni
>> modos... Entonces la pregunta es:
>>
>> Que posibilidades hay de mantener una replica en linea retrasada X
>> tiempo (casi una semana, por ejemplo) pero que se pudiera administrar la
>> aplicación de los WAL de forma manual, para permitir  operaciones
>> como  (todas  ojala dentro de una transaccion  para poder devolver el
>> cambio en el caso que uno se 'pasara' de la hora del suceso):
>>
>>
>> - Aplicación de cambios hasta un timestamp defnido
>> - Aplicación de WAL interactivamente, algo como aplique el siguiente WAL
>> para que por tanteo se pueda llegar a los datos mas próximos antes de la
>> calamidad
>>
>> Y con todas las bondades de las replicas en linea. Muchas gracias Lista
>> y quedo atento a sus comentarios.
>>
>>
>>
>>
>>
>>
>>
>> --
>> Cordialmente,
>>
>> Ing. Hellmuth I. Vargas S.
>> Esp. Telemática y Negocios por Internet
>> Oracle Database 10g Administrator Certified Associate
>> EnterpriseDB Certified PostgreSQL 9.3 Associate
>>
>>


-- 
Cordialmente,

Ing. Hellmuth I. Vargas S.
Esp. Telemática y Negocios por Internet
Oracle Database 10g Administrator Certified Associate
EnterpriseDB Certified PostgreSQL 9.3 Associate

RE: [pgsql-es-ayuda] No puedo instalar / ejecutar postgresql 9.3

[Hellmuth Vargas]

Hola

Lo puede descargar de aquí:

http://www.enterprisedb.com/products-services-training/pgdownload
El oct. 29, 2015 12:09 PM, "MKHotmail"  escribió:

> Hice todo lo indicado desde un primer momento, a excepción de los puntos 5
> y 6.
>
>
>
> De donde descargo ese instalador ¿?
>
>
>
> Gracias por la ayuda..
>
>
>
> MK
>
>
>
>
>
> *De:* pgsql-es-ayuda-ow...@postgresql.org [mailto:
> pgsql-es-ayuda-ow...@postgresql.org] *En nombre de *jvenegasperu .
> *Enviado el:* jueves, 29 de octubre de 2015 11:47 a.m.
> *Para:* MKHotmail 
> *CC:* Ayuda 
> *Asunto:* Re: [pgsql-es-ayuda] No puedo instalar / ejecutar postgresql 9.3
>
>
>
> Hola
> intenta seguir estas sugerencias
>
> 1.- Primero desinstala luego borra todo rastro de postres en windows las
> carpetas incluido el registro
> 2.- instala postgres con permisos de asdministrador
>
> 3.- No pongas la carpeta data dentro de archivos de programa ponlo en otra
> carpeta fuera de archivos de programa si es posible en otra unidad mejor
>
> 4.- usa el mismo usuario y contraseñe de postgres seguro tu instalacion
> con problemas ya creo un usuario postgres.
>
> 5.- Si aun tienes problemas probablemente te este faltando las bibliotecas
> de Visual C++ para tu version de postgres tendrias que ver tu version de
> postgres cual usa.
>
> 6.- El instalador de EDB trae incluido las librerias de VC asi que te
> sugiero bajar el instalador de enterprise db para windows y ejecutar los
> pasos.
>
> saludos
>
>
>
>
>
> El 28 de octubre de 2015, 17:11, MKHotmail 
> escribió:
>
> Maestros intente instalar Postgresql 9.3 en un servidor Windows Server
> 2003. No me dejaba instalar me salta este error, lo hice desde una
> instalación limpia y me sale ese error que no me deja instalar…busque en
> internet y no encuentro rptas.
>
>
>
> Agradeceré a bien guiarme en esta instalación, en otras maquinas no tuve
> problemas….
>
>
>
>
>
>
>
>
> --
>
> José Mercedes Venegas Acevedo
> cel Mov RPM #955853768
>
> mails: jvenegasp...@gmail.com
>

Re: [pgsql-es-ayuda] Consulta que no tome en cuenta las tildes

[Hellmuth Vargas]

Hola lista

Y porque no considerar FTS?
El oct. 22, 2015 12:30 PM, "Hellmuth Vargas" <hiv...@gmail.com> escribió:

> Hola Mauricio y lista
>
>
> Yo le sugeriría emplear FTS (FULL TEXT SEARCH ENGINE) pues maneja tanto
> las tildes como mayúsculas/minúsculas. El ejemplo básico (sin indices,
> columnas precalculadas, etc) es:
>
>
> SELECT  *
> FROM (VALUES ('perro'),('Método'),(
> 'MÉTODO'),('metodo'),('casa'),('lote')) AS a(dato)
>  WHERE to_tsvector('spanish',a.dato) @@ plainto_tsquery('método');
>
>
>   dato
> 
>  Método
>  MÉTODO
>  metodo
>
> (3 rows)
>
>
>
>
>
>
>
> El 22 de octubre de 2015, 12:09 p. m., mauricio pullabuestan<
> jmaurici...@yahoo.es> escribió:
>
>> Buen día
>>
>> Tengo una tabla personal con un campo cargo en donde el usuario puede
>> ingresar los cargos, existe registros en donde ingresa "Métodos" o
>> "Metodos" lo cual es un problema.
>>
>> En Sql Server hay un parámetro de configuración donde le indicaba no
>> distinguir acentos y otro parámetro para no distinguir entre mayúsculas y
>> minúsculas y a los sql no tienen nada de especial.
>>
>> Existe en postgresq algo similar?
>>
>> Quiero evitar hacer esto:
>>
>> SELECT codigo, nombres
>> FROM personal
>> where cargo ILIKE '%Métodos%' Or cargo ILIKE '%Metodos%'
>> ORDER BY nombres;
>>
>> Saludos.
>> Mauricio
>>
>
>
>
> --
> Cordialmente,
>
> Ing. Hellmuth I. Vargas S.
> Esp. Telemática y Negocios por Internet
> Oracle Database 10g Administrator Certified Associate
> EnterpriseDB Certified PostgreSQL 9.3 Associate
>
>

Re: [pgsql-es-ayuda] Consulta que no tome en cuenta las tildes

[Hellmuth Vargas]

Hola Mauricio y lista


Yo le sugeriría emplear FTS (FULL TEXT SEARCH ENGINE) pues maneja tanto las
tildes como mayúsculas/minúsculas. El ejemplo básico (sin indices, columnas
precalculadas, etc) es:


SELECT  *
FROM (VALUES ('perro'),('Método'),( 'MÉTODO'),('metodo'),('casa'),('lote'))
AS a(dato)
 WHERE to_tsvector('spanish',a.dato) @@ plainto_tsquery('método');


  dato

 Método
 MÉTODO
 metodo

(3 rows)







El 22 de octubre de 2015, 12:09 p. m., mauricio pullabuestan<
jmaurici...@yahoo.es> escribió:

> Buen día
>
> Tengo una tabla personal con un campo cargo en donde el usuario puede
> ingresar los cargos, existe registros en donde ingresa "Métodos" o
> "Metodos" lo cual es un problema.
>
> En Sql Server hay un parámetro de configuración donde le indicaba no
> distinguir acentos y otro parámetro para no distinguir entre mayúsculas y
> minúsculas y a los sql no tienen nada de especial.
>
> Existe en postgresq algo similar?
>
> Quiero evitar hacer esto:
>
> SELECT codigo, nombres
> FROM personal
> where cargo ILIKE '%Métodos%' Or cargo ILIKE '%Metodos%'
> ORDER BY nombres;
>
> Saludos.
> Mauricio
>



-- 
Cordialmente,

Ing. Hellmuth I. Vargas S.
Esp. Telemática y Negocios por Internet
Oracle Database 10g Administrator Certified Associate
EnterpriseDB Certified PostgreSQL 9.3 Associate

Re: [pgsql-es-ayuda] ayuda con funcion List

[Hellmuth Vargas]

Hola Igniris

Según indica,  debe tener una versión que soporta string_agg pues lo
verificó directamente en consola y funcionó,  es posible que lo este
molestando es la comillas sencilla (') si esta embebiendo la sentencia en
una cadena.  Si puede copiar el pedazo de código donde emplea la sentencia
para poder analizar mejor el problema

>
> >
> > >
> > > SELECT
> > >  string_agg(distinct p.nombre,',') as prod,
> > >  string_agg(distinct fa.forma,',') as forma
> > > FROM
> > >   public.producto p
> > >   INNER JOIN public.productoformaadquisclugar pfl ON (p.id =
pfl.idproducto)
> > >   INNER JOIN public.formadeadquisicion fa ON (pfl.idforma = fa.id)

>
> >
> > >
> > >

El oct. 9, 2015 7:27 AM, "Igniris" <ivaldi...@xetid.cu> escribió:

> Muchas gracias Hellmuth probe con tu solucion y en la consulta funciono,
> pero cuando lo pongo en la funcion de la app reaal me da error de sintaxis
> como este:
>
> 'Doctrine_Connection_Pgsql_Exception' with message 'SQLSTATE[42601]: Syntax 
> error: 7
>
> si lo quito y lo pongo como estaba funciona pero con la deficiencia que les 
> comentaba inicialmente, saludos y gracias
>
>
>
> El 07/10/2015 a las 08:46 a. m., Hellmuth Vargas escribió:
>
> Hola Igniris
>
> Pruebalo con string_agg así:
>
>
> SELECT
>  string_agg(distinct p.nombre,',') as prod,
>  string_agg(distinct fa.forma,',') as forma
> FROM
>   public.producto p
>   INNER JOIN public.productoformaadquisclugar pfl ON (p.id =
> pfl.idproducto)
>   INNER JOIN public.formadeadquisicion fa ON (pfl.idforma = fa.id)
>
> El 7 de octubre de 2015, 9:37 a. m., Igniris<ivaldi...@xetid.cu> escribió:
>
>> Buenos dias a todos
>> tengo un problema con la funcion LIST les pongo un ejemplo para ilustralo
>> mejor, tengo las siguientes tablas:
>> CREATE TABLE public.producto (
>>   id NUMERIC NOT NULL,
>>   nombre TEXT,
>>   CONSTRAINT producto_pkey PRIMARY KEY(id)
>> ) WITHOUT OIDS;
>> CREATE TABLE public.formadeadquisicion (
>>   id NUMERIC NOT NULL,
>>   forma TEXT,
>>   CONSTRAINT formadeadquisicion_pkey PRIMARY KEY(id)
>> ) WITHOUT OIDS;
>> CREATE TABLE public.productoformaadquisclugar (
>>   idproducto NUMERIC NOT NULL,
>>   idforma NUMERIC NOT NULL,
>>   idlugar NUMERIC NOT NULL,
>>   CONSTRAINT productoformaadquisc_pkey PRIMARY KEY(idproducto, idforma,
>> idlugar)
>> ) WITHOUT OIDS;
>>
>> Ahora tengo una consulta para obtener los producto por su forma de
>> adquisicion donde necesito los nombres de los productos y las formas
>> concatenados, la consulta seria esta:
>> SELECT
>>  LIST(p.nombre) as prod,
>>  LIST(fa.forma)as forma
>> FROM
>>   public.producto p
>>   INNER JOIN public.productoformaadquisclugar pfl ON (p.id =
>> pfl.idproducto)
>>   INNER JOIN public.formadeadquisicion fa ON (pfl.idforma = fa.id)
>>
>> el resultado de la consulta queda asi:
>>
>>
>> ahora el problema que estoy teniendo es que los usuarios necesitan que si
>> el producto se repite salga una sola vez, en este ejemplo el mango sale 2
>> veces y necesito que salga solo una, la funcion list que estoy usando es
>> esta:
>>
>> CREATE FUNCTION comma_cat(text, text) RETURNS text
>> LANGUAGE sql
>> AS $_$select case
>> WHEN $2 is null or $2 = '' THEN $1
>> WHEN $1 is null or $1 = '' THEN $2
>> ELSE $1 || ', ' || $2
>> END$_$;
>> CREATE AGGREGATE list (
>> BASETYPE = text,
>> SFUNC = comma_cat,
>> STYPE = text,
>> INITCOND = ''
>> );
>>
>> Muchas gracias por su ayuda, saludos
>>
>
>
>
> --
> Cordialmente,
>
> Ing. Hellmuth I. Vargas S.
> Esp. Telemática y Negocios por Internet
> Oracle Database 10g Administrator Certified Associate
> EnterpriseDB Certified PostgreSQL 9.3 Associate
>
>
>

Re: [pgsql-es-ayuda] ayuda con funcion List

[Hellmuth Vargas]

Hola Igniris

Pruebalo con string_agg así:


SELECT
 string_agg(distinct p.nombre,',') as prod,
 string_agg(distinct fa.forma,',') as forma
FROM
  public.producto p
  INNER JOIN public.productoformaadquisclugar pfl ON (p.id = pfl.idproducto)
  INNER JOIN public.formadeadquisicion fa ON (pfl.idforma = fa.id)

El 7 de octubre de 2015, 9:37 a. m., Igniris escribió:

> Buenos dias a todos
> tengo un problema con la funcion LIST les pongo un ejemplo para ilustralo
> mejor, tengo las siguientes tablas:
> CREATE TABLE public.producto (
>   id NUMERIC NOT NULL,
>   nombre TEXT,
>   CONSTRAINT producto_pkey PRIMARY KEY(id)
> ) WITHOUT OIDS;
> CREATE TABLE public.formadeadquisicion (
>   id NUMERIC NOT NULL,
>   forma TEXT,
>   CONSTRAINT formadeadquisicion_pkey PRIMARY KEY(id)
> ) WITHOUT OIDS;
> CREATE TABLE public.productoformaadquisclugar (
>   idproducto NUMERIC NOT NULL,
>   idforma NUMERIC NOT NULL,
>   idlugar NUMERIC NOT NULL,
>   CONSTRAINT productoformaadquisc_pkey PRIMARY KEY(idproducto, idforma,
> idlugar)
> ) WITHOUT OIDS;
>
> Ahora tengo una consulta para obtener los producto por su forma de
> adquisicion donde necesito los nombres de los productos y las formas
> concatenados, la consulta seria esta:
> SELECT
>  LIST(p.nombre) as prod,
>  LIST(fa.forma)as forma
> FROM
>   public.producto p
>   INNER JOIN public.productoformaadquisclugar pfl ON (p.id =
> pfl.idproducto)
>   INNER JOIN public.formadeadquisicion fa ON (pfl.idforma = fa.id)
>
> el resultado de la consulta queda asi:
>
>
> ahora el problema que estoy teniendo es que los usuarios necesitan que si
> el producto se repite salga una sola vez, en este ejemplo el mango sale 2
> veces y necesito que salga solo una, la funcion list que estoy usando es
> esta:
>
> CREATE FUNCTION comma_cat(text, text) RETURNS text
> LANGUAGE sql
> AS $_$select case
> WHEN $2 is null or $2 = '' THEN $1
> WHEN $1 is null or $1 = '' THEN $2
> ELSE $1 || ', ' || $2
> END$_$;
> CREATE AGGREGATE list (
> BASETYPE = text,
> SFUNC = comma_cat,
> STYPE = text,
> INITCOND = ''
> );
>
> Muchas gracias por su ayuda, saludos
>



-- 
Cordialmente,

Ing. Hellmuth I. Vargas S.
Esp. Telemática y Negocios por Internet
Oracle Database 10g Administrator Certified Associate
EnterpriseDB Certified PostgreSQL 9.3 Associate

[pgsql-es-ayuda] No funciona WITH con mas de 2 sentencias DML

[Hellmuth Vargas]

Hola Lista

Estaba realizando un cargue de un archivo Excel con información de clientes
bancarios con tarjeta para un call center poblando un modelo maestro,
detalle  y tabla de llamadas telefónicas. En un principio se implemento por
medio de una herramienta de ETL con los controles que ofrece la herramienta
ETL y para bases de 10.000 registros duraba hasta 3 horas si no se caída
por memoria, por lo tanto me lo asignaron para optimizarlo y decidí
realizar  las operaciones de ordenamiento, limpieza y filtro de datos
 directamente en la base de datos (donde es natural) aun empleando el
cascaron de la herramienta de ETL (pues debe integrase con otro sistema);
dentro de uno de los pasos, ya para insertar  los datos en las diferentes
tablas, implemente un código similar al siguiente empleando WITH:


WITH base AS (
INSERT INTO maestro (
fechacreacion, fechamodificacion, idusuariocrea,
departamento, documento, municipio, primerapellido,
primernombre,  telefono1,  tipodocumento, direccion, email)
SELECT now(), now(), 1,a.departamento ,a.documento,a.ciudad,
a.apellidos,a.nombres, a.telefono_1,
a.tipo_identificacion,a.direccion_residencia , a.e_mail
FROM  tmp_carga
GROUP BY a.departamento ,a.documento,a.ciudad, a.apellidos,a.nombres,
a.telefono_1, a.tipo_identificacion,a.direccion_residencia , a.e_mail
RETURNING id,documento

), insertadetalle AS (
INSERT INTO detalle(
codigooficina,
   direccionoficina, franquicia, montodisponible, nombreproducto,
tipoproducto, ultimosdigitos, maestro_id)

   SELECT a.Codigo_Interno,
a.Cod_Oficina,a.DireccionOficina,a.Franquicia_tarjeta, a.MontoDisponible,
a.Nombre_Producto,a.Tipo_Producto,a.ultimos_digitos_tc,b.id
FROM vys.tmp_carga as a
JOIN base as b on a.documento=b.documento
RETURNING maestro_id

)
INSERT INTO
marcadortelefonia
(
numerointento,
telefono,
telefono2,
telefono3,
telefono4,
fechacreacion,
maestro_id,
calificacion
)
SELECT
1,
a.telefono1,
a.telefono2,
a.telefono3,
a.telefono4,
current_timestamp,
a.id,
0
FROM
maestro as a
JOIN base as b --tambien probe sustituyendo base por insertadetalle y
tampoco
ON a.id=b.id



El tema es que no ejecuta el ultimo INSERT (sobre marcadortelefonia): si
inserta los datos en maestro y en  detalle, pero cuando consulto sobre
marcadortelefonia no hay nada y tampoco genera error. En resumen, no sirve
emplear  un WITH con mas de dos sentencias DML.? o estoy haciendo algo mal?
 de antemano muchas gracias lista

Cordialmente,

Ing. Hellmuth I. Vargas S.

Re: [GENERAL] [pgsql-es-ayuda] No funciona WITH con mas de 2 sentencias DML

[Hellmuth Vargas]

Hola Alvaro...

mmm devolviendo ademas el teléfono desde base... mmm no lo había
considerado.. Mil Gracias

2015-10-06 14:01 GMT-05:00 Alvaro Herrera <alvhe...@2ndquadrant.com>:

> Hellmuth Vargas escribió:
>
> > Realice este pequeño laboratorio para presentar la inquietud:
>
> WITH base AS (
> INSERT INTO master (identificacion, nombre, telefono)
> SELECT a.identificacion, a.nombre, a.telefono
> FROM carga AS a
> GROUP BY a.identificacion, a.nombre, a.telefono
> RETURNING id, telefono, identificacion
>
> ),
> insertadetalle AS (
> INSERT INTO detalle (tarjeta, master_id)
> SELECT a.tarjeta,b.id
> FROM carga AS a
> JOIN base as b ON a.identificacion =
> b.identificacion
> RETURNING master_id
> )
> INSERT INTO
> marcadortelefonia
> (
> telefono,
> master_id
> )
> SELECT b.telefono, b.identificacion::int
> FROM base b
> GROUP BY b.telefono, b.identificacion::int;
>
> ???
>
> --
> Álvaro Herrerahttp://www.2ndQuadrant.com/
> PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
>



-- 
Cordialmente,

Ing. Hellmuth I. Vargas S.
Esp. Telemática y Negocios por Internet
Oracle Database 10g Administrator Certified Associate
EnterpriseDB Certified PostgreSQL 9.3 Associate

Re: [GENERAL] [pgsql-es-ayuda] No funciona WITH con mas de 2 sentencias DML

[Hellmuth Vargas]

Hola Alvaro

Gracias por la pronta respuesta

Alvaro Herrera wrote:
Hmm, yo creo que sí funciona y no lo estás usando bien.  No tengo tiempo
ahora para mirar tu query, pero me parece raro que en el FROM no hagas
referencia a insertadetalle, y también me parece raro que hagas
referencia directa a maestro cuando deberías hacerlo a base.

Lo hice de varias  formas:
1. empleando el resultado de insertadetalle
2. con base solo y
3. con base haciendo join con maestro


Realice este pequeño laboratorio para presentar la inquietud:


create table carga (
identificacion  text,nombre text,tarjeta text, telefono text
);

insert into carga(identificacion  ,nombre ,tarjeta , telefono)
values
 ('1','Juan', 'tarjeta 1', '1234'),
 ('1','Juan', 'tarjeta 2', '1234'),
 ('2','German', 'tarjeta 1', '5678'),
 ('3','Pedro', 'tarjeta 1', '90123'),
 ('3','Pedro', 'tarjeta 2', '90123');

create table master (
id serial primary key,
identificacion  text,nombre text, telefono text
);



create table detalle (
id serial,
tarjeta  text,
master_id int references master(id)
);

create table marcadortelefonia (
id serial,
telefono text,
master_id int references master(id)
);




WITH base AS (
INSERT INTO master (identificacion,nombre, telefono)
SELECT a.identificacion,a.nombre,a.telefono
FROM  carga as a
GROUP BY a.identificacion,a.nombre,a.telefono
RETURNING id,identificacion

)
, insertadetalle AS (
INSERT INTO detalle(tarjeta,master_id)
SELECT a.tarjeta,b.id
FROM carga as a
JOIN base as b on a.identificacion=b.identificacion
RETURNING master_id

)
INSERT INTO
marcadortelefonia
(
telefono,
master_id
)
SELECT
b.telefono,
a.id
*FROM base as a join master as b on a.id <http://a.id>=b.id <http://b.id>*
group by b.telefono,a.id;


select count(*) from master; --  3 registros
select count(*) from detalle; -- 5 registros
select count(*) from marcadortelefonia; -- 0 registros


-
-- version 2
-


WITH base AS (
INSERT INTO master (identificacion,nombre, telefono)
SELECT a.identificacion,a.nombre,a.telefono
FROM  carga as a
GROUP BY a.identificacion,a.nombre,a.telefono
RETURNING id,identificacion

)
, insertadetalle AS (
INSERT INTO detalle(tarjeta,master_id)
SELECT a.tarjeta,b.id
FROM carga as a
JOIN base as b on a.identificacion=b.identificacion
RETURNING master_id

)
INSERT INTO
marcadortelefonia
(
telefono,
master_id
)
SELECT
b.telefono,
a.master_id
*FROM insertadetalle as a join master as b on a.master_id=b.id
<http://b.id>*
group by b.telefono,a.master_id;

select count(*) from master; --  3 registros
select count(*) from detalle; -- 5 registros
select count(*) from marcadortelefonia; -- 0 registros



 Muchas gracias!!




El 6 de octubre de 2015, 11:11 a. m., Alvaro Herrera<alvhe...@alvh.no-ip.org
> escribió:

> Francisco Olarte wrote:
> > Alvaro, Hellmuth no se si os habies dado cuenta pero estais copiando
> > mensaje entre la lista en Español y la general ( es posible que si
> > teneis las dos suscritas os haya eliminado los duplicados, yo solo
> > tengo la -general en ingles y me han llegado )
> >
> > ( Intencionalmente sin copia a las listas, solo FYI ).
>
> Ups, no me di cuenta :-(
>
> /me spanks Hellmuth
>
> Ya que estamos, aprovecho de decir que creo que serías un buen aporte a
> la lista en español :-)
>
> Saludos
>
> > 2015-10-06 17:51 GMT+02:00 Alvaro Herrera <alvhe...@2ndquadrant.com>:
> > > Hellmuth Vargas escribió:
> > >> Hola Lista
> > >>
> > >> Estaba realizando un cargue de un archivo Excel con información de
> clientes
> > .
> > > Hmm, yo creo que sí funciona y no lo estás usando bien.  No tengo
> tiempo
> > > ahora para mirar tu query, pero me parece raro que en el FROM no hagas
> > 
>
>
> --
> Álvaro Herrera PostgreSQL Expert,
> http://www.2ndQuadrant.com/
> "Oh, great altar of passive entertainment, bestow upon me thy discordant
> images
> at such speed as to render linear thought impossible" (Calvin a la TV)
>



-- 
Cordialmente,

Ing. Hellmuth I. Vargas S.
Esp. Telemática y Negocios por Internet
Oracle Database 10g Administrator Certified Associate
EnterpriseDB Certified PostgreSQL 9.3 Associate

[pgsql-es-ayuda] Fwd: actualización de versión de replicas PostgreSQL Streaming Replication

[Hellmuth Vargas]

-- Mensaje reenviado --
De: "Hellmuth Vargas" <hiv...@gmail.com>
Fecha: sept. 30, 2015 8:47 AM
Asunto: actualización de versión de replicas PostgreSQL Streaming
Replication
Para: "Lista Postgres ES" <pgsql-es-ayuda@postgresql.org>
Cc:

Hola Lista

Tengo una base de datos PostgreSQL 9.3 de aproximadamente 600GB con dos
replica en Streaming Replication. Para la actualización en las versiones
anteriores, siempre debía migrar la master y luego regenerar las replicas,
recientemente publicaron en la documentación de PostgreSQL 9.5 (
http://www.postgresql.org/docs/9.5/static/pgupgrade.html punto 9, Upgrade
Streaming Replication and Log-Shipping standby servers ) un procedimiento
para realizar una actualización  rápida de las replicas,  realice un
laboratorio para migrar de 9.3 a 9.4 aplicando el procedimiento y si
funciona (hasta el momento), la pregunta es, se puede emplear para migrar
desde  otras versiones, lo pregunto porque ademas tengo un par de
PostgreSQL  9.2  y un PostgreSQL  9.1 de tamaños similares todas con
replicas. Muchas Gracias Lista.

-- 
Cordialmente,

Ing. Hellmuth I. Vargas S.

[pgsql-es-ayuda] actualización de versión de replicas PostgreSQL Streaming Replication

[Hellmuth Vargas]

Hola Lista

Tengo una base de datos PostgreSQL 9.3 de aproximadamente 600GB con dos
replica en Streaming Replication. Para la actualización en las versiones
anteriores, siempre debía migrar la master y luego regenerar las replicas,
recientemente publicaron en la documentación de PostgreSQL 9.5 (
http://www.postgresql.org/docs/9.5/static/pgupgrade.html punto 9, Upgrade
Streaming Replication and Log-Shipping standby servers ) un procedimiento
para realizar una actualización  rápida de las replicas,  realice un
laboratorio para migrar de 9.3 a 9.4 aplicando el procedimiento y si
funciona (hasta el momento), la pregunta es, se puede emplear para migrar
desde  otras versiones, lo pregunto porque ademas tengo un par de
PostgreSQL  9.2  y un PostgreSQL  9.1 de tamaños similares todas con
replicas. Muchas Gracias Lista.

-- 
Cordialmente,

Ing. Hellmuth I. Vargas S.

Re: [pgsql-es-ayuda] Buscar datos en detalle

[Hellmuth Vargas]

Buenos días Lista

Verificar con esta

Select *

from cabecera x inner join detalles y on
(x.numero_formulario=y.numero_formulario) join (
Select y.numero_formulario from detalles as y group by 1
Except
Select y.numero_formulario from detalles as y where y.codigo_producto not
in (1))  as z on y.numero_formulario = z.numero_formulario
El sept. 13, 2015 7:43 AM, "Carlos Perez" 
escribió:

> Perdon no puse código porque estoy respondiendo del celular y tengo dedos
> de morcilla. Prometo que en cuanto agarre una pc escribo.
> El query de francisco es correcto pero faltaria buscarle la vuelta para
> usar = y <> reemplazando el in() que en definitiva es una función.si
>  el código tiene un indice podes probar lo lo
> que te comenté escribiendo delante de ambas consultas explain plan...
> Lo que comento es para que una vez hecha tu consulta te olvides para
> siempre de la misma y no tengas problemas futuros si esas tablss crecen con
> millones de registros.
> Espero haber sido claro, disculpen lo escueto pero igual de cada parte de
> lo  escrito la comunidad dedico capitulos enteros que son mejores que esta
> explicacion que solo busca orientar.
>
> Enviado con Aquamail para Android
> http://www.aqua-mail.com
>
>
> El 13 de septiembre de 2015 09:15:55 Horacio Miranda 
> escribio:
>
>
>>
>> On 9/13/2015 11:31 PM, José Fermín Francisco Ferreras wrote:
>>
>>> select *
>>> from cabecera x inner join detalles y on
>>> (x.numero_formulario=y.numero_formulario)
>>> where y.codigo_producto not in (1)
>>>
>>>
>> select *
>> from cabecera x,detalles y
>> where
>> x.numero_formulario=y.numero_formulario and
>> y.codigo_producto not in (1) ;
>>
>>
>> Prueba con esto por favor.
>>
>> Pero lo hace mal, ya que lo que hace es excluirme del listado los
>>> formularios donde aparecen las naranjas.
>>>
>>> Y lo que se desea seleccionar los formularios donde no existen naranjas
>>> facturadas.
>>>
>>>
>>>
>>> ing. José Fermín Francisco Ferreras
>>> San Francisco de Macorís, Rep. Dom.
>>>
>>>
>>>  > Subject: Re: [pgsql-es-ayuda] Buscar datos en detalle
>>>  > To: josefermi...@hotmail.com; pgsql-es-ayuda@postgresql.org
>>>  > From: hmira...@gmail.com
>>>  > Date: Sun, 13 Sep 2015 15:25:32 +1200
>>>  >
>>>  > Copia y pega lo que tienes de tu SQL, que problema tienes ?
>>>  >
>>>  > On 9/13/2015 2:12 PM, José Fermín Francisco Ferreras wrote:
>>>  > > Ejemplo de lo que se necesita:
>>>  > >
>>>  > > numero_formulario: 1
>>>  > > Productor: 64
>>>  > > fecha: 05/09/2015
>>>  > > hora: 08:56:00
>>>  > > Monto_Total: 5000.00
>>>  > > numero_formulario: 1
>>>  > > codigo_producto: 1
>>>  > > Producto: Naranja
>>>  > > Cantidad: 5
>>>  > >
>>>  > > numero_formulario: 2
>>>  > > Productor: 2
>>>  > > fecha: 06/09/2015
>>>  > > hora: 10:00:00
>>>  > > Monto_Total: 14500.00
>>>  > > numero_formulario: 2
>>>  > > codigo_producto: 2
>>>  > > Producto: Pera
>>>  > > Cantidad: 2
>>>  > > numero_formulario: 2
>>>  > > codigo_producto: 1
>>>  > > Producto: Naranja
>>>  > > Cantidad: 3
>>>  > >
>>>  > > numero_formulario: 3
>>>  > > Productor: 10
>>>  > > fecha: 05/09/2015
>>>  > > hora: 13:30:00
>>>  > > Monto_Total: 4500.00
>>>  > > numero_formulario: 3
>>>  > > codigo_producto: 3
>>>  > > Producto: Piña
>>>  > > Cantidad: 1
>>>  > >
>>>  > > numero_formulario: 4
>>>  > > Productor: 11
>>>  > > fecha: 10/09/2015
>>>  > > hora: 13:50:00
>>>  > > Monto_Total: 11800.00
>>>  > > numero_formulario: 4
>>>  > > codigo_producto: 3
>>>  > > Producto: Piña
>>>  > > Cantidad: 1
>>>  > > numero_formulario: 4
>>>  > > codigo_producto: 2
>>>  > > Producto: Pera
>>>  > > Cantidad: 1
>>>  > > numero_formulario: 4
>>>  > > codigo_producto: 4
>>>  > > Producto: Sandia
>>>  > > Cantidad: 6
>>>  > >
>>>  > > Cuando ejecute la consulta debería desplegar los resultados
>>>  > > correspondientes a los formularios #3 y #4, ya que en esos no se
>>> facturó
>>>  > > ninguna naranja.
>>>  > >
>>>  > > Nota: Este ejemplo lo represento como si hubiera hecho un join de
>>> las
>>>  > > tablas.
>>>  > >
>>>  > >
>>>  > >
>>>  > > ing. José Fermín Francisco Ferreras
>>>  > > San Francisco de Macorís, Rep. Dom.
>>>  > >
>>>  > >
>>>  > > > Subject: Re: [pgsql-es-ayuda] Buscar datos en detalle
>>>  > > > To: josefermi...@hotmail.com; pgsql-es-ayuda@postgresql.org
>>>  > > > From: hmira...@gmail.com
>>>  > > > Date: Sun, 13 Sep 2015 13:34:03 +1200
>>>  > > >
>>>  > > >
>>>  > > >
>>>  > > > On 9/13/2015 10:52 AM, José Fermín Francisco Ferreras wrote:
>>>  > > > > Buenas tardes!!
>>>  > > > >
>>>  > > > > Estoy teniendo problemas con una consulta. Resulta que necesito
>>>  > > > > consultar en dos tablas:
>>>  > > > > -Maestro
>>>  > > > > numero_formulario**
>>>  > > > > productor
>>>  > > > > fecha
>>>  > > > > hora
>>>  > > > > monto_total
>>>  > > > >
>>>  > > > > detalles
>>>  > > > > numero_formulario*-
>>>  > > > > codigo_producto
>>>  > > > > producto
>>>  > > > > cantidad
>>>  > > > >
>>>  > > > > 

Re: [pgsql-es-ayuda] Buscar datos en detalle

[Hellmuth Vargas]

Hola lista

Me falto un group by :-P

Select *

from cabecera x inner join detalles y on
(x.numero_formulario=y.numero_formulario) join (
Select y.numero_formulario from detalles as y group by y.numero_formulario
Except
Select y.numero_formulario from detalles as y where y.codigo_producto not
in (1) group by y.numero_formulario )  as z on y.numero_formulario =
z.numero_formulario
El sept. 13, 2015 8:23 AM, "Hellmuth Vargas" <hiv...@gmail.com> escribió:

> Buenos días Lista
>
> Verificar con esta
>
> Select *
>
> from cabecera x inner join detalles y on
> (x.numero_formulario=y.numero_formulario) join (
> Select y.numero_formulario from detalles as y group by 1
> Except
> Select y.numero_formulario from detalles as y where y.codigo_producto not
> in (1))  as z on y.numero_formulario = z.numero_formulario
> El sept. 13, 2015 7:43 AM, "Carlos Perez" <carlos.pe...@syswarp.com.ar>
> escribió:
>
>> Perdon no puse código porque estoy respondiendo del celular y tengo dedos
>> de morcilla. Prometo que en cuanto agarre una pc escribo.
>> El query de francisco es correcto pero faltaria buscarle la vuelta para
>> usar = y <> reemplazando el in() que en definitiva es una función.si
>> <http://xn--funcin-fxa.si> el código tiene un indice podes probar lo lo
>> que te comenté escribiendo delante de ambas consultas explain plan...
>> Lo que comento es para que una vez hecha tu consulta te olvides para
>> siempre de la misma y no tengas problemas futuros si esas tablss crecen con
>> millones de registros.
>> Espero haber sido claro, disculpen lo escueto pero igual de cada parte de
>> lo  escrito la comunidad dedico capitulos enteros que son mejores que esta
>> explicacion que solo busca orientar.
>>
>> Enviado con Aquamail para Android
>> http://www.aqua-mail.com
>>
>>
>> El 13 de septiembre de 2015 09:15:55 Horacio Miranda <hmira...@gmail.com>
>> escribio:
>>
>>
>>>
>>> On 9/13/2015 11:31 PM, José Fermín Francisco Ferreras wrote:
>>>
>>>> select *
>>>> from cabecera x inner join detalles y on
>>>> (x.numero_formulario=y.numero_formulario)
>>>> where y.codigo_producto not in (1)
>>>>
>>>>
>>> select *
>>> from cabecera x,detalles y
>>> where
>>> x.numero_formulario=y.numero_formulario and
>>> y.codigo_producto not in (1) ;
>>>
>>>
>>> Prueba con esto por favor.
>>>
>>> Pero lo hace mal, ya que lo que hace es excluirme del listado los
>>>> formularios donde aparecen las naranjas.
>>>>
>>>> Y lo que se desea seleccionar los formularios donde no existen naranjas
>>>> facturadas.
>>>>
>>>>
>>>>
>>>> ing. José Fermín Francisco Ferreras
>>>> San Francisco de Macorís, Rep. Dom.
>>>>
>>>>
>>>>  > Subject: Re: [pgsql-es-ayuda] Buscar datos en detalle
>>>>  > To: josefermi...@hotmail.com; pgsql-es-ayuda@postgresql.org
>>>>  > From: hmira...@gmail.com
>>>>  > Date: Sun, 13 Sep 2015 15:25:32 +1200
>>>>  >
>>>>  > Copia y pega lo que tienes de tu SQL, que problema tienes ?
>>>>  >
>>>>  > On 9/13/2015 2:12 PM, José Fermín Francisco Ferreras wrote:
>>>>  > > Ejemplo de lo que se necesita:
>>>>  > >
>>>>  > > numero_formulario: 1
>>>>  > > Productor: 64
>>>>  > > fecha: 05/09/2015
>>>>  > > hora: 08:56:00
>>>>  > > Monto_Total: 5000.00
>>>>  > > numero_formulario: 1
>>>>  > > codigo_producto: 1
>>>>  > > Producto: Naranja
>>>>  > > Cantidad: 5
>>>>  > >
>>>>  > > numero_formulario: 2
>>>>  > > Productor: 2
>>>>  > > fecha: 06/09/2015
>>>>  > > hora: 10:00:00
>>>>  > > Monto_Total: 14500.00
>>>>  > > numero_formulario: 2
>>>>  > > codigo_producto: 2
>>>>  > > Producto: Pera
>>>>  > > Cantidad: 2
>>>>  > > numero_formulario: 2
>>>>  > > codigo_producto: 1
>>>>  > > Producto: Naranja
>>>>  > > Cantidad: 3
>>>>  > >
>>>>  > > numero_formulario: 3
>>>>  > > Productor: 10
>>>>  > > fecha: 05/09/2015
>>>>  > > hora: 13:30:00
>>>>  > > Monto

[pgsql-es-ayuda] Storage sugerido para base de datos PostgreSQL OLTP sobre Linux

[Hellmuth Vargas]

Hola lista

Estamos cotizando un nuevo servidor para nuestra actual base de datos
PostgreSQL 9.4 sobre Linux con 2500 usuarios concurrentes de call center.
Que storage  y sus características actualmente se esta empleando para
servidores de base de datos dedicados que brinden rendimiento,
escalabilidad y durabilidad y que otros criterios deberian considerarse...
De antemano muchas gracias lista

RE: [pgsql-es-ayuda] Storage sugerido para base de datos PostgreSQL OLTP sobre Linux

[Hellmuth Vargas]

Hola Enrique

Si tiene toda la razón no envíe unos datos importantes

Tamaño en disco de la base se datos: 546GB


Linux 2.6.32-220.4.2.el6.x86_64 (Mpc72-BD)  28/08/15 _x86_64_
(12 CPU)

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
  13,630,003,68   12,120,00   70,57

Device:tps   Blk_read/s   Blk_wrtn/s   Blk_read Blk_wrtn
sdb   0,00 0,00 0,00  0 0
sda 563,00 28488,00  6248,00  28488 6248

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
  14,580,004,70   10,630,00   70,10

Device:tps   Blk_read/s   Blk_wrtn/s   Blk_read Blk_wrtn
sdb   0,00 0,00 0,00  0 0
sda 565,00 33344,00  7568,00  33344 7568

En cuanto las características de colectividad escuchamos propuestas!!
Muchas gracias

Hola Hellmuth

Tengo 3 dudas.

1.- Que tamaño tienen tus bases.

2.-Cual es i/o que tienes actualmente.

3.- Las características de tu server de conectividad cual seria.

Esto es porque por ejemplo yo tengo 6 storage  y te comento.

*Tengo 2 Power voul.. (DELL con disco sas de 15 mil). Esto lo tengo en
arreglo 5 y me soporta la operación de 7 mil puntos. Pero las consultas es
muy lento.

*Tengo 2 PV (Dell también pero hidrido). Este soporta las mismas
operaciones pero es más rápido y esto es porque los I/O son mas por el
arreglo.

* tengo 2 equalogic SSD y por ejemplo estos me soportan lo mismo y las
consultas son aceptables. Pero en este caso tengo un arreglo 6. (yo le dijo
6 pero se le conoce también como 60 en la consola del storage).

Estos 3 exenarios es porque la conectividad de cada uno es diferente y
obviamente su tamaño también.

Mi recomendación es no solo veas que storage sino que vas a usar y como lo
vas a conectar. Si deseas con todo gusto te apoyamos. JAJAJ NO VENDO NADA
pero si tenemos un poco de exp. En storage DELL e IBM ya que nuestra compra
que estamos haciendo es un storage flash.

Y si en algo puedo apoyarte y puedo avísame.

Saludos





*De:* pgsql-es-ayuda-ow...@postgresql.org [
mailto:pgsql-es-ayuda-ow...@postgresql.org
pgsql-es-ayuda-ow...@postgresql.org] *En nombre de *Hellmuth Vargas
*Enviado el:* viernes, 28 de agosto de 2015 11:01
*Para:* Lista Postgres ES
*Asunto:* [pgsql-es-ayuda] Storage sugerido para base de datos PostgreSQL
OLTP sobre Linux



Hola lista

Estamos cotizando un nuevo servidor para nuestra actual base de datos
PostgreSQL 9.4 sobre Linux con 2500 usuarios concurrentes de call center.
Que storage  y sus características actualmente se esta empleando para
servidores de base de datos dedicados que brinden rendimiento,
escalabilidad y durabilidad y que otros criterios deberian considerarse...
De antemano muchas gracias lista

Re: [pgsql-es-ayuda] Data-checksums en una cluster preexistente

[Hellmuth Vargas]

Hola lista

El jul. 31, 2015 3:27 PM, Jaime Casanova jaime.casan...@2ndquadrant.com
escribió:

 2015-07-30 9:13 GMT-05:00 Hellmuth Vargas hiv...@gmail.com:
 
  Hola Lista
 
  Tengo un cluster de base de datos PostgreSQL 9.3 con diposnibilidad
7x24,
  que viene siendo actualizada desde la verison 8.4, por lo tanto no
cuenta
  con el mecanismo de data-checksums y las escasas ventanas de
mantenimiento
  para actualizar version,  solo permiten ejecutar  pg_upgrade pues la
  disponibilidad no se puede ver afectada mucho tiempo, exite algun
  proedimiento o script o programa que permitiera habilitar la opción de
  data-checksums en un cluster preexistente sin mucha indisponibilidad,
algo
  que permitiera como:
 
  - Colocar el cluster en modo backup
  - Ejecutar un script, programa, procedimiento que calcule y setee
  data-checksums
  - Habilitar en data-checksums en los parámetros del servidor cluster.
  - terminar el modo backup.
 
 

 No como lo presentas, puedes usar slony para replicar a otra máquina
 (o a la misma en otro puerto) que tenga el checksum activo. Luego
 haces un switchover que no te tomará más de unos minutos

Mmmm..  No lo había considerado, voy a evaluarlo..  Muchas gracias Alvaro y
Jaime por sus respuestas
 --
 Jaime Casanova  www.2ndQuadrant.com
 Professional PostgreSQL: Soporte 24x7 y capacitación

[pgsql-es-ayuda] Data-checksums en una cluster preexistente

[Hellmuth Vargas]

Hola Lista

Tengo un cluster de base de datos PostgreSQL 9.3 con diposnibilidad 7x24,
que viene siendo actualizada desde la verison 8.4, por lo tanto no cuenta
con el mecanismo de data-checksums y las escasas ventanas de mantenimiento
para actualizar version,  solo permiten ejecutar  pg_upgrade pues la
disponibilidad no se puede ver afectada mucho tiempo, exite algun
proedimiento o script o programa que permitiera habilitar la opción de
data-checksums en un cluster preexistente sin mucha indisponibilidad, algo
que permitiera como:

- Colocar el cluster en modo backup
- Ejecutar un script, programa, procedimiento que calcule y setee
data-checksums
- Habilitar en data-checksums en los parámetros del servidor cluster.
- terminar el modo backup.

Re: [pgsql-es-ayuda] version 9.3.5_ actualizar?

[Hellmuth Vargas]

los 5 primeros son:

01539897540437562499562988




Descartando 0 y 1 seleccionaría 539897y ese debería ser el valor con el que
debo setear en pg_database:

update pg_database set datminmxid='539897'::xid where
datname='bd_secundaria' and oid='16431'::oid.

antes de ejecutar el UPDATE para validar y/o confirmar hago un  hexdump
del archivo :


[root@Mpc72-BD offsets]# hexdump -C 0008 | more
  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00
||
*
f3e0  00 00 00 00 01 00 00 00  03 00 00 00 05 00 00 00
||
f3f0  07 00 00 00 09 00 00 00  0b 00 00 00 0d 00 00 00
||
f400  0f 00 00 00 11 00 00 00  13 00 00 00 15 00 00 00
||
f410  17 00 00 00 19 00 00 00  1b 00 00 00 1d 00 00 00
||
f420  1f 00 00 00 21 00 00 00  23 00 00 00 25 00 00 00
|!...#...%...|
f430  27 00 00 00 29 00 00 00  2b 00 00 00 2d 00 00 00
|'...)...+...-...|
f440  2f 00 00 00 31 00 00 00  33 00 00 00 35 00 00 00
|/...1...3...5...|
f450  37 00 00 00 39 00 00 00  3b 00 00 00 3d 00 00 00
|7...9...;...=...|
f460  3f 00 00 00 41 00 00 00  43 00 00 00 45 00 00 00
|?...A...C...E...|
f470  47 00 00 00 49 00 00 00  4b 00 00 00 4d 00 00 00
|G...I...K...M...|
f480  4f 00 00 00 51 00 00 00  53 00 00 00 55 00 00 00
|O...Q...S...U...|
f490  57 00 00 00 59 00 00 00  5b 00 00 00 5d 00 00 00
|W...Y...[...]...|
f4a0  5f 00 00 00 61 00 00 00  63 00 00 00 65 00 00 00
|_...a...c...e...|
f4b0  67 00 00 00 69 00 00 00  6b 00 00 00 6d 00 00 00
|g...i...k...m...|
f4c0  6f 00 00 00 71 00 00 00  73 00 00 00 75 00 00 00
|o...q...s...u...|
f4d0  77 00 00 00 79 00 00 00  7b 00 00 00 7d 00 00 00
|w...y...{...}...|
f4e0  7f 00 00 00 81 00 00 00  83 00 00 00 85 00 00 00
||
f4f0  87 00 00 00 89 00 00 00  8b 00 00 00 8d 00 00 00
||
f500  8f 00 00 00 91 00 00 00  93 00 00 00 95 00 00 00
||
f510  97 00 00 00 99 00 00 00  9b 00 00 00 9d 00 00 00
||
f520  9f 00 00 00 a1 00 00 00  a3 00 00 00 a5 00 00 00
||
f530  a7 00 00 00 a9 00 00 00  ab 00 00 00 ad 00 00 00
||
f540  af 00 00 00 b1 00 00 00  b3 00 00 00 b5 00 00 00
||
f550  b7 00 00 00 b9 00 00 00  bb 00 00 00 bd 00 00 00
||
f560  bf 00 00 00 c1 00 00 00  c3 00 00 00 c5 00 00 00
||
f570  c7 00 00 00 c9 00 00 00  cb 00 00 00 cd 00 00 00
||
f580  cf 00 00 00 d1 00 00 00  d3 00 00 00 d5 00 00 00
||
f590  d7 00 00 00 d9 00 00 00  db 00 00 00 dd 00 00 00
||
f5a0  df 00 00 00 e1 00 00 00  e3 00 00 00 e5 00 00 00
||
f5b0  e7 00 00 00 e9 00 00 00  eb 00 00 00 ed 00 00 00
||
f5c0  ef 00 00 00 f1 00 00 00  f3 00 00 00 f5 00 00 00
||
f5d0  f7 00 00 00 f9 00 00 00  fb 00 00 00 fd 00 00 00
||
f5e0  ff 00 00 00 01 01 00 00  03 01 00 00 05 01 00 00
||
f5f0  07 01 00 00 09 01 00 00  0b 01 00 00 0d 01 00 00
||
f600  0f 01 00 00 11 01 00 00  13 01 00 00 15 01 00 00
||
f610  17 01 00 00 19 01 00 00  1b 01 00 00 1d 01 00 00
||
f620  1f 01 00 00 21 01 00 00  23 01 00 00 25 01 00 00
|!...#...%...|

Pero pasa lo mismo, no se que debo interpretar aqui... inlcuso tengo duda
del valor que me arrojo el query (539897) por lo que menciona Alvaro (cito)

El problema es que si has consumido una gran cantidad de multiacts,
podrían haber valores que estén pasados del punto medio de wraparound, o
haber dado la vuelta completa...



Entonces tengo la duda que procedimiento debo seguir en estos casos, mil
Gracias Alvaro.




El 1 de junio de 2015, 4:35 p. m., Alvaro Herreraalvhe...@2ndquadrant.com
escribió:

 Hellmuth Vargas escribió:
  Hola Alvaro
 
  Desarrolle este pequeño script para actualizar en cada base los valores
 de
  datminmxid,
 
  select oid, datminmxid , datname from pg_database;
 
  update pg_database as x
  set datminmxid=y.nuevo
  from (
  select relminmxid as nuevo from pg_class where (cast(cast(relminmxid AS
  text) AS bigint))0 and (cast(cast(relminmxid AS text) AS bigint))1
  order by (cast(cast(relminmxid AS text) AS bigint)) asc limit 1
  ) as y
  where x.datname='crm_seguro' and x.oid='16438'::oid;
 
  Está bien?  Puedo dejar este valor así?

 Ni idea.  ¿por qué no muestras un select oid, relminmxid from pg_class
 where relminmxid  '0', a ver si tiene sentido?  El problema es que si
 has consumido una gran cantidad de multixacts, podrían haber valores que
 estén pasados el punto medio de wraparound, o haber dado la vuelta
 completa, y las comparaciones normales  y  podrían no tener sentido ...

  Lo estoy ejecutando y no genera error sin embargo lo estoy haciendo
  sobre las bases que se pueden recuperar fácil de un backup

 Me parece sensato!

  De antemano muchas gracias..  Me surge una