[pgsql-es-ayuda] Re: [pgsql-es-ayuda] Índices sobre constraints foreign key

[Francisco Olarte]

Ivan:

2017-06-10 3:33 GMT+02:00 Ivan Perales M. <ivan.pera...@gmail.com>:
> En algun momento del pasado, honestamente no recuerdo si leí o escuché que
> postgres por default creaba indices sobre las columnas que tienen un
> constraint foreign key.  Ya que el rendimiento siempre ha sido óptimo y no
> he tenido problemas, realmente no me habia dado a la tarea de investigar al
> respecto.
>
> Sin embargo acabo de leer un comentario que dice que ningun rdbms crea
> indices sobre éstas columnas por que lo que uno debe crearlos si es
> necesario.

Muchos RDBMS crean indices para PK porque PK implica not-null, unique,
y muchos implementan unique creando un indice unico.

Por otro lado FK no implica UNIQUE, y no necesita indice en general,
se chequea de hecho rapido con el indice de la PK. Solo si vas a hacer
muchas referencias por el campo ( teniendo en cuenta las implicitas,
como p.e. borrados en la pk ) le hace falta, y aun asi hay veces que
un indice por FK puro no te interesa ( puedes tener p.e. un combo
FK+timestamp que te interese mas).

Recuerda ademas que los indices no son gratis.

Ahora, lo de que ninguno lo cree parece muy atrevido, pero bueno, el
que lo pusiera sabra.

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

[pgsql-es-ayuda] Re: [pgsql-es-ayuda] calculo preciso de años meses y dias

[Francisco Olarte]

Estimado Felix:

Añado la lista en CC que no iba en tu mensaje original.

2017-05-16 13:18 GMT+02:00 felix gonzales <jfgonza...@gmail.com>:
> Estimado Francisco
> de manera "manual", me refiero a mirar un calendario (por ejemplo del
> sistema operativo o el que tienes pegado en la pared) y contar los meses y
> días entre dos fechas. por ejemplo del 15-02-2017 al 01-05-2017. Desde el 15
> de febrero hasta el 15 de abril tenemos 2 meses y del 16 de abril al 01 de
> mayo hay 16 días. resultado final: 2 meses y 16 días.

La parte de mirar el calendario la dabamos por echa. La parte de contar tambien.

El data point que nos das nos dice que en parte lo quires hacer
contando hacia adelante, hasta ahi bien.

Ahora solo nos falta que nos digas que hay que hace cuando sobran
dias, p.e. que hay que hacer cuando vas del 30 de enero al 13 de
marzo. El 30 de febrero no existe, luego que haces en ese caso,
cuentas dos dias para ir al 1 de febrero mas 28 para ir al 1 de marzo
mas 13 extra para llegar al 13 de marzo, dandote 43 dias, o cuentas un
mes para ir del penultimo dia de enero al penultimo ( 27 ) de febrero,
mas 1 dia para terminar febrero mas 13 dias para llegar al 13 de marzo
dando un toal de 1 mes y 14 dias, o cuentas 1 mes para ir del 30 de
enero al 30 de febrero = 2 de marzo mas 11 dias para llegar a 1 mes y
11 dias?


A lo que voy, y parece que no consigo que me entiendas, es a que si
describes adecuadamente un proceso manual quizas te podamos decir como
automatizarlo, pero si te limitas a dar un datapoint de "En este caso
concreto que me da 2m16d querria 2m16d" poco podemos hacer. Incluso
con la descripcion algo, aunque no mucho, mas prolija que has dado
siguen quedando muchos casos que no se sabe que hacer con ellos. De
hecho dudo mucho que tu hayas pensado en como hacerlo a mano. Es un
problema clasico con las rutinas de fechas. Sale algo que no te gusta,
parece que lo hace mal y que la forma correcta es "evidente" hasta que
empiezas a rascar y ves que no lo es tanto.

Por eso los que llevamos muchos años con estas cosas no decimos "la
forma manual evidente", lo intentamos en el pasado repetidas veces y
sabemos que no existe.

Saludos
   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

[pgsql-es-ayuda] Re: [pgsql-es-ayuda] calculo preciso de años meses y dias

[Francisco Olarte]

Felix:

2017-05-15 15:16 GMT+02:00 felix gonzales <jfgonza...@gmail.com>:
> Necesito obtener años meses y días precisos. utilizando la función AGE tengo
> la dificultad que la primera y ultima linea me devuelve lo mismo, alguna
> alternativa?

Dejando aparte algunas cosas que ya te han dicho, puedes definir "años
meses y dias precisos".

> select AGE('29-04-2017','15-02-2017');
> select AGE('30-04-2017','15-02-2017');
> select AGE('01-05-2017','15-02-2017');

> cualquier comentario bienvenido.

Tu problema es el clasico cuando usas intervalos (age). El sistema
intenta ser de utilidad separandote años/meses y dias, pero como los
meses no son todos iguales te pasa eso. Si eres capaz de dar una
definicion exacta de lo que quieres igual se te puede dar una
solucion. Eso si, la definicion suele ser mucho mas dificil de dar de
lo que parece, yo no me fiaria de ninguna de menos de un par de folios
en tu caso.

Porque postgres cree que te esta dando meses y dias precisos en ese
caso, y probablemente para su definision lo son.

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

Re: [pgsql-es-ayuda] Duda sobre varias consultas simultaneas

[Francisco Olarte]

Ligeramente fuera de contexto pero.

On Thu, May 11, 2017 at 10:49 PM, Maximiliano Riffo <maxrif...@gmail.com> wrote:
> where tiempobajada::timestamp::time between '08:00:00' and '09:00:00' and

Un timestamp, o u time, es conceptualmente un numero real ( una
distancia a un instante de tiempo fijo, p.e. ). Between da intervalos
cerrados. Los intervalos cerrados no suelen combinar bien con los
numeros reales porque es imposible cubrir la recta SIN sobreposicion
con ellos. No parece que cree el problema tuyo en este caso, pero en
general suele ser mejor usar time <= '08:00:00' and time < '09:00:00'.

( Esto da tipos de errores similares, pero no parecen los tuyos, p.e.
si tienes un punto cada minuto exacto y usas ese tipo de codigo para
contar te puedes encontrar que tienes 1441 puntos en un dia, pero 61
puntos por hora, que sumados te dan 1464, porque cuentas los extremos
varias veces ) ( Y la respuesta a 'ya, pero nunca voy a tener
:00.00' exacto suele ser que te ocurre a la primera ejecucion
o a la demo con el cliente )

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

Re: [pgsql-es-ayuda] retornar valor en transaccion

[Francisco Olarte]

Marco, copio de nuevo a la lista, con todo el texto, por si alguien
esta siguiendo el thread. Recuerda, reply to all.

2017-04-18 19:08 GMT+02:00 Marco Vinicio Jimenez Rojas <vinici...@gmail.com>:
> vieras que interesante, ya probé con el .executeQuery, justamente pensé que
> eso podría ser el problema pero, no me cambio nada,
> Lo que observo es que es que cuando hago la consulta en el Query del pgAdmin
> cuando retorna valores me dice:
> 35 rows retrieved. en la la consola de mensajes y en data output muestra las
> filas de las de la consulta.
> Pero con la transacción en cuestión dice:
> "query result with 2 rows discarded." en la consola de mensaje y el Data
> Output no aparece nada.

ESA es precisamente la razon por la que te debes aprender a manejar el
psql de linea de comando y a copiar/pegar desde las ventanas de
comando de tu SO ( Que no se cual es, pero temo windows ). El PGADMIN
es un programa EXTREMADAMENTE COMPLEJO que hace sus cosas apartes y
que muchos no usamos ni conocemos, y al ser grafico las interacciones
son muy dificiles de describir.

Esto tiene toda la pinta de que estas mandando varios comandos. No se
como va el pgadmin, pero creo recordar que salvo que lo configures de
alguna forma rara el se encarga de mandarte los begin end etc..

> Siento que eso tiene que ver en el porque no tengo resultado tampoco en
> java.

¿ No estaras mandando en el "String sql" que pasas a al statement el
texto "begin transaction" y "commit/rollback" ? ( SI es asi eso NO SE
HACE ).

Haz una prueba CON EL PSQL mandando SOLO EL QUERY DEL INSERT, y mira
que te da ( y pega la sesion si no es lo que esperas, manda el query,
si no te funciona pega DESDE QUE ENTRAS HASTA EL FINAL. Al ser el psql
mas sencillo es mas facil ver que te esta pasando, pero todo esto
tiene pinta de problemas con las herramientas. No tengo ni idea de
como delinea las transacciones el pg-admin, pero el jdbc si que se que
las delinea 'modo oracle', es decir, si esta en autocommit cada
comando en una transaccion, si no todo en una transaccion hasta que
llamas a connection.commit() o .rollback() ).

Francisco Olarte.

P.S. A mi personalmente me gusta mas el modo por defecto del PSQL,
estas en autocommit hasta que mandas begin, porque te permite cambiar
facilmente el modo de transaccionar, pero que se le va a hacer.

-
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] retornar valor en transaccion

[Francisco Olarte]

Marco:

2017-04-18 15:45 GMT+02:00 Marco Vinicio Jimenez Rojas <vinici...@gmail.com>:
> Disculpa con lo del correo, gmail me lo oculta y entonces no me doy cuenta.

Sin problema. En otro orden de cosas, acuerdate que el reply-to de las
listas de postgres, por motivos historicos, apunta al emisor, con lo
que hay que darle al reply-all en google ( no se como saldra si lo
tienes en castellano, yo lo uso en ingles, la flecha curvada doble ).
He reañadido la lista en copia y quoteare de mas para recuperar el
contexto.

> Tengo dos tablas, veamoslo como un encabezado y un detalle donde el detalle
> una relación N-n, entonces, entonces quiero hacer todos los insert de manera
> completa y por eso uso la transaccion.

Lo del master-detail lo habia pillado. Lo de la transaccion es
innecesario, ya que tu query es un solo comando, y eso va siempre en
una sola transaccion ( puede haber varios comandos por transaccion,
pero no al reves ).

> en Java uso el JDBC, con un queryupdate

AHI esta tu problema. Un insert-returning se comporta, como te dije en
mis mensajes anteriores, como un select.

> consultaSQL_TJ = conexionTJ.createStatement();
> consultaSQL_TJ.executeUpdate(sql, Statement.RETURN_GENERATED_KEYS);
> ResultSet rs = consultaSQL_TJ.getGeneratedKeys();
> if(rs.next())
> {
>res = rs.getInt(1);
> }

Este trozo es para cuando haces un insert SIN RETURNING y quieres que
te de, p.e., los valores de los serial que no has puesto explicitos (
Yo personalmente no lo recomiendo, el returning te da mas control ).

Lo que tienes que hacer es cambiar a hacer un execute sin mas, si mi
jdbc no me falla no es mas que hacer:

consultaSQL_TJ = conexionTJ.createStatement();
ResultSet rs =consultaSQL_TJ.executeQuery(sql);
if(rs.next())
...

Y pon los nombres de columnas que insertas ( o, si los has puesto,
copia los queries que usas, no los rehagas ).

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

Re: [pgsql-es-ayuda] retornar valor en transaccion

[Francisco Olarte]

Marco:

2017-04-18 1:06 GMT+02:00 Marco Vinicio Jimenez Rojas <vinici...@gmail.com>:
> Tengo la siguiente transacción en la cual necesito utilizar el valor del
> "returning id_roles" fuera de la transacción. todo funciona bien pero no me
> sale ese dato por ningún lado

Cuando 'no te sale' que quieres decir? Eso parece un trozo de script
medio pegado, si se lo metes al psql ¿ que hace / imprime ?. Nota, si
estas usando algo tipo el pgAdmin este puede estar recibiendo el dato
y no mostrarlo, pero para depurar esas cosas necesitarias contar
exactamente la secuencia que usas y los programas y versiones ( el
psql es mas sencillo para estos reports, lo arrancas, le pegas el
query, imprimira algo, cortas el texto de la pantalla entera y lo
pegas, por eso te lo digo ).

> begin transaction;
> with roles as(
> insert INTO ovinos.roles VALUES(default,'prueba rol','el primer rol de
> prueba',2) returning id_rol
> )
> insert INTO ovinos.funciones_roles VALUES(4,(select roles.id_rol from
> roles)),
> (5,(select roles.id_rol from roles))returning id_roles;

Parece correcto PERO no poner los nombres de las columnas en las que
estas insertando es 1.- Pedir problemas a medio plazo y 2.- una
dificultad añadida para que te digamos nada ya que no sabemos
siquierea como se llaman las columnas en las tablas.

Una prueba similar ( sin schemas ) me funciona sin problemas:
http://sqlfiddle.com/#!15/92ae0/1/0

Y por el estilo del report esto tiene toda la pinta de ser problemas
con la herramienta de queries que estas usando.


> commit;
> ROLLBACK TRANSACTION;

¿ Porque commit + rollback ?

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

Re: [MASSMAIL]Re: [pgsql-es-ayuda] restriccion check

[Francisco Olarte]

Gilberto:

2017-04-05 18:46 GMT+02:00 Gilberto Castillo <gilberto.casti...@etecsa.cu>:
>>> 2017-04-05 16:46 GMT+02:00 Gilberto Castillo
>>> <gilberto.casti...@etecsa.cu>:
>>>>> 2017-04-05 16:22 GMT+02:00 Pedro PG <pedr...@outlook.com>:
>>>>>> Lo que deseo es agregar una restriccion CHECK que solo permita
>>>>>> modificar
>>>>>> datos de la tupla si y solo si liquidado es NULL.
>>>>>
>>>>> Igual estoy un poco oxidado, pero las restricciones check lo que hacen
>>>>> es comprobar un juego de valores de la tupla, no miran si vienen de
>>>>> update o de lo que sea.
>>>>>
>>>>>> 1) Cuando se inserta un registro el campo liquidado siempre sera NULL
>>>>>> (esto
>>>>>> es correcto).
>>>>>> 2) Desde un procedimiento externo actualizare liquidado (esto tambien
>>>>>> es
>>>>>> correcto).
>>>>>> 3) Si deseo actualizar el registro, solo debe permitirme si el campo
>>>>>> liquidado es NULL (aqui mi problema).
>>>>>
>>>>> Probablemente puedes hacer eso con un trigger. De todas formas, salvo
>>>>> que estes haciendo el control con roles y mucho cuidado, porque no
>>>>> pones un 'where liquidadoull' extra en los updates? Tambien podrias
>>>>> probar con un "create rule x on update to table where OLD.liquidado is
>>>>> not null instead do nothing' o algo asi, pero te puede dar problemas
>>>>> si quieres revertir una fila a liquidadoull. Al fin y al cabo, si
>>>>> alguien puede cambiar liquidado a null probablemente pueda hacer
>>>>> not-null->null->update->null.
>>>>
>>>> Yo Usaría UPSERT
>>>
>>> Iluminanos, porfa. Hacer eso con upsert seria un truco fantastico.
>
> insert into mytabla as a (campo1, liquidado)
> values ('valor1',1),('valor2',null)
> on conflict (liquidado)
> do update set
> liquidado = a.liquidado + EXCLUDED.liquidado
>  where a.liquidado IS NULL;

Te tomaste la molestia de leer un poco por encima lo que pedia?

Suponiendo que asi fuera ( que yo personalmente creo que no pero
siempre hay que otorgar el beneficio de la duda):

1.- Su problema es evitar updates, no inserts., lo pone en el punto 3.

2.- Y aunque no insertase siempre null, el campo de liquidado NO es unico.

3.- De hecho el punto 1 de la pregunta dice que insert SIEMPRE es null
en insercion, lo que hace que NUNCA haya conflictos de insercion en
liquidado.

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

Re: [MASSMAIL]Re: [pgsql-es-ayuda] restriccion check

[Francisco Olarte]

Gilberto:

2017-04-05 16:46 GMT+02:00 Gilberto Castillo <gilberto.casti...@etecsa.cu>:
>> 2017-04-05 16:22 GMT+02:00 Pedro PG <pedr...@outlook.com>:
>>> Lo que deseo es agregar una restriccion CHECK que solo permita modificar
>>> datos de la tupla si y solo si liquidado es NULL.
>>
>> Igual estoy un poco oxidado, pero las restricciones check lo que hacen
>> es comprobar un juego de valores de la tupla, no miran si vienen de
>> update o de lo que sea.
>>
>>> 1) Cuando se inserta un registro el campo liquidado siempre sera NULL
>>> (esto
>>> es correcto).
>>> 2) Desde un procedimiento externo actualizare liquidado (esto tambien es
>>> correcto).
>>> 3) Si deseo actualizar el registro, solo debe permitirme si el campo
>>> liquidado es NULL (aqui mi problema).
>>
>> Probablemente puedes hacer eso con un trigger. De todas formas, salvo
>> que estes haciendo el control con roles y mucho cuidado, porque no
>> pones un 'where liquidado=null' extra en los updates? Tambien podrias
>> probar con un "create rule x on update to table where OLD.liquidado is
>> not null instead do nothing' o algo asi, pero te puede dar problemas
>> si quieres revertir una fila a liquidado=null. Al fin y al cabo, si
>> alguien puede cambiar liquidado a null probablemente pueda hacer
>> not-null->null->update->null.
>
> Yo Usaría UPSERT

Iluminanos, porfa. Hacer eso con upsert seria un truco fantastico.

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

Re: [pgsql-es-ayuda] restriccion check

[Francisco Olarte]

Pedro:

2017-04-05 16:22 GMT+02:00 Pedro PG <pedr...@outlook.com>:
> Lo que deseo es agregar una restriccion CHECK que solo permita modificar
> datos de la tupla si y solo si liquidado es NULL.

Igual estoy un poco oxidado, pero las restricciones check lo que hacen
es comprobar un juego de valores de la tupla, no miran si vienen de
update o de lo que sea.

> 1) Cuando se inserta un registro el campo liquidado siempre sera NULL (esto
> es correcto).
> 2) Desde un procedimiento externo actualizare liquidado (esto tambien es
> correcto).
> 3) Si deseo actualizar el registro, solo debe permitirme si el campo
> liquidado es NULL (aqui mi problema).

Probablemente puedes hacer eso con un trigger. De todas formas, salvo
que estes haciendo el control con roles y mucho cuidado, porque no
pones un 'where liquidado=null' extra en los updates? Tambien podrias
probar con un "create rule x on update to table where OLD.liquidado is
not null instead do nothing' o algo asi, pero te puede dar problemas
si quieres revertir una fila a liquidado=null. Al fin y al cabo, si
alguien puede cambiar liquidado a null probablemente pueda hacer
not-null->null->update->null.


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

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

[Francisco Olarte]

Baru:

2017-03-24 14:12 GMT+01:00 baru gerardi <soyb...@gmail.com>:
> Soy novato y miraré en detalle las respuestas para aprender.

Mira tambien los manuales. Yo personalmente recomiendo el original,
que es un ingles muy asequible sobre todo en la parte de referencias
de funciones.


> Si me permiten, una pregunta mas
> Exista alguna manera dentro del substring como para posicionarme
> en la cadena de texto con una subcadena y de ahi tomar un desplazamiento?
> Disculpen el invento, pero imagino algo del tipo
> substring(texto, 'DNI:', n)

De ahi lo de leer el manual, en la pagina donde describe el substring
te cuenta, justo debajo de la variante de substring con indices
numericos:

substring(string from pattern) text Extract substring matching POSIX
regular expression. See Section 9.7 for more information on pattern
matching.

De ahi, viendo el ejemplo, puedes hacer substring(texto from
'DNI:.') ( con n puntos, o si lo prefieres mira los
cuantificadores en la referencia de los pattern ).

No solo eso, sino que justo encima del substring clasico con enteros
(substring(string [from int] [for int]) tienes la function
position(substring in string). De esas puedes sacar la solucion
clasica para lo que quieres ( en muchos lenguajes no tienes la que
quieres, pero tienes una que busca y otra que corta ). Vamos, divide
et impera:

$ select position('DNI:' in 'TEL:22 DNI:123456789 AGE:66');
 position
--
8
(1 row)

$ select substring('TEL:22 DNI:123456789 AGE:66' from position('DNI:'
in 'TEL:22 DNI:123456789 AGE:66')+4 for 8);
 substring
---
 12345678
(1 row)

$ select substring('TEL:22 DNI:123456789 AGE:66' from position('DNI:'
in 'TEL:22 DNI:123456789 AGE:66')+char_length('DNI:') for 8);
 substring
---
 12345678
(1 row)

( La ultima es para que veas como podrias meterlo todo en una funcion )

> Algo asi de sencillo resolveria mi problema, que es muy básico

Complicado no es, es mas o menos lo mismo que en los lenguajes mas normales.

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

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

[Francisco Olarte]

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.

-
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] Substring y expresiones regulares

[Francisco Olarte]

Gerardo:

2017-03-23 17:57 GMT+01:00 Gerardo Herzig <gher...@fmed.uba.ar>:
>> 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

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

[Francisco Olarte]

2017-03-23 17:13 GMT+01:00 baru gerardi <soyb...@gmail.com>:
> 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
> pero necesito que liste de ahí en adelante los nros que encuentre, teniendo
> en cuenta:
> 1. que desconozco cuantos espacios hay entre 'DNI:' y el primer dígito y
> 2. que puede haber puntos entre los dígitos

Esa es la tipica tarea para expresiones regulares.

Por desgracia tambien es un problema poco especificado.

Suponiendo que lo que quieres es buscar -
  - "DNI:"
  - seguido por un numero indeterminado de espacios.
  - seguido por una cadena de digitos que puede tener puntos de
separacion en medio.
( y no dices nada de la letra, si son españoles ultimamante la tienen )

Solo con lo de los digitos y puntos:

select x, regexp_matches(x, 'DNI:\s*(\d+(?:\.\d+)*)') from
regexp_split_to_table('malo/xx DNI: 12 22/yy DNI:12.22.33 zz','/') as
t(x);
 x  | regexp_matches
+
 xx DNI: 12 22  | {12}
 yy DNI:12.22.33 zz | {12.22.33}
(2 rows)

Que puede ser lo que quieres o no, pero de ahi puedes elaborar. En la
regexp que hay tenemos, por partes:

DNI: - busca eso
\s* un numero indeterminado (*) de espacios.
( capturamos
\d+ uno o mas (+) digitos (\d) opcionales
(?: mas una sub-secuencia compuesta por
   \. Un punto ( el punto a secas es un comodin )
   \d+ y digitos
)* fin de subsecuencia, repetida un numero indeterminado de veces.
) fin de captura.

Francisco Olarte.



>
> Desde ya, gracias por la ayuda
> Saludos
> Baru
>
>
>
> --
> lo que está y no se usa nos fulminará

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

Re: [pgsql-es-ayuda] problemas con el recolector de estadisticas

[Francisco Olarte]

2017-03-23 11:54 GMT+01:00 Kernel <jucab...@gmail.com>:
> mi base de datos ha empezado a ralentizarse, en los log apararece los
> siguente :
> usando estadadisticas viejas en vez de actualizadas porque el recolector de
> estadisticas no esta respondiendo
> Agradeceria cualquier tipo de ayuda

Asi de cara parece como que se te ha parado el autovacuum, que es el
proceso que se encarga de hacerlo, lo cual te podria provocar bastante
ralentizacion especialmente si tienes claves autoincrementadas, o
timestamps de eventos actuales, en tus queries ( ya que si, p.e., se
para en febrero y preguntas por marzo supondra que no hay datos, y
usara un plan correcto pero potencialmente muy malo si hay registros
de marzo , o si se paro en el ID 1000 y preguntas por ID 1500 a 2000).

De todas formas sospecho que lo que has puesto no es el contenido
original del log ( mas que otra cosa por la falta de ortografia en
esta*da*disticas, cuando 10 palabras mas alla esta bien escria ). Si
es asi podrias poner el log original ( con el que se puede intentar
ver cual es la causa. Yo personalmente solo uso postgres en ingles,
con doc en ingles, con un log que se correcto puedo buscar el original
y mirar algo de las docs, pero con ese ni lo voy a intentar ).

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

Re: [pgsql-es-ayuda] migracion de versiones

[Francisco Olarte]

Maria Antonieta:

2017-03-23 0:35 GMT+01:00 Maria Antonieta Ramirez <marami...@ulsaneza.edu.mx>:
> Me interesa la parte de como restaurar por partes, me pueden decir donde
> puedo leer mas acerca de esto, para aprender a hacerlo porfavor.

Primero, tu uso del top posting, especialmente con un mensaje
cualqueira como origen, hace casi imposible saber a que parte del hilo
te refieres.

En cuanto a localizacion de info, todo lo que te digo viene
documentado en las paginas del pg_dump/pg_restore, que estan dentro de
"postgresql client applications" en el manual.

Dicho esto, yo recuerdo haber dicho algo de restaurar por partes. Me
explico un poco mas.

Cuando haces un backup (con pg_dump) de una instancia de postgres al
restaurarla lo que haces es basicamente ejecutar un script SQL
gigante.

El pg_dump sin parametros, en formato texto, lo que hace es montarte
directamente ese script. Las unicas ventajas que (IMO) tiene ese
metodo es que se puede comprimir algo mas ( aunque yo jamas he
encontrado un caso en el que mereciese la pena por eso ) y que puede
contener en un solo archivo varias bases de datos y las definiciones
globales ( usuarios y roles ) del servidor.

Cuando yo tengo que hacer una migracion lo que hago es primero volcar
en formato texto las variables globales ( pg_dumpall -g, como te
indicaba Jaime ). Esto te da un script SQL pequeño que es facil de
arreglar si tienes que cambiar algo aprovechando la migracion o
arreglar algo por diferencias extremas de versiones.

Tras ello vuelco cada base de datos en formato custom, pg_dump -Fc.
Este formato es similar a un tar con elementos comprimidos en el
interior, o a un zip, pero especifico para postgres. Este formato te
hace lo mismo que el de texto, ya que un pg_restore sin mas de un dump
te da el mismo script sql que un pg_dump a script.

Pero el pg_restore puede hacer mas cosas. Una de ellas es conectar a
la BD que le digas y mandar el sql alli sin pasar por disco,
evidentemente. Otra es listarte lo que hay dentro del backup (
pg_restore -l ) que es lo que yo uso para restaurar por partes. Esa
opcion te da un listado comentado de lo que hay dentro del arhivo en
el orden en que lo va a procesar. Es como un script de control de
restauracion. La cosa es que ese listado lo puedes mandar con la
opcion -L de vuelta al pg_restore, lo que no es muy interesante. Pero
tambien puedes editarlo, trozearlo, reordenarlo o borrar cachos y
usarlos despues.

Yo he usado eso, p.e., para resolver un problema de roles. El backup
iba bien hasta que llegaba a una tabla que tenia un problema de
encodings, si no recuerdo mal. Lo que hacia era partir la lista del -l
en dos cachos, ejecutar el primero, pasar un pequeño trozo de sql que
hice para arreglar las cosas y despues pasar el segundo.

Tambien lo he usado para reordenar un par de tablas. Primero
restauraba ese par de tablas en un server auxiliar y las reorganizaba
y hacia un backup de esas dos. Luego editaba el listado para restaurar
hasta esas tablas del original, en medio restauraba las tablas
reorganizadas de la copia, y detras restauraba lo que venia detras de
las tablas originales.

Y otra cosa para lo que lo uso mucho es para las particiones. Nosotros
tenemos mucho dato en tablas particionadas por fechas ( de insercion
mas o menos ). Cuando restauro una de estas puedo editar el listado
para restaurar las tablas maestras de las particiones y la particion
actual, poner el sistema en servicio ( degradado por que no se puede
consultar el historico, pero es util ) y despues voy restaurando las
particiones de historico ( de hecho uno de los tipos de
reorganizaciones que he hecho como te contaba arriba es particionar
tablas que no lo estaban ).

Basicamente lo de ir por partes es parecido a editar el archivo sql
gigante, pero mas comodo cuando el volumen de datos es grande.

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

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

[Francisco Olarte]

Buenas tardes:

2017-03-21 0:35 GMT+01:00 Mario Sileone (GM) <msile...@gmail.com>:
> Tengo una consulta respecto a las tablas divididas. Tenemos una división
> en tablas que tienen millones de registros diarios, en tablas heredadas
> mensuales.

De las que iria muy bien que pudieramos ver algo para saber como son.

> 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 que puede tener varios motivos ..

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

... explain que vendria bien pudiesemos ver.

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

Aparte de la solucion que ya te apuntan, construir la consulta con una
funcion, los datos que te comento vendrian bien. Ten en cuenta que las
funciones de timestamp WITH y WITHOUT timezone son truculentas, ya que
muchas veces las funciones de conversion de una a otra son volatiles (
dependen del timezone de la conexion ), y mirando el explain se puede
ver a veces como hay conversiones de tipo en un caso que no hay en
otro. ( p.e. now() exige una conversion si usas timestamp without time
zone en la tabla, pero '2017-03-24 12:34:56' no. Sin embargo con
timezone ninguna lo necesita. Y si le pones zona a la constante lo
puede necesitar. Por eso yo normalmente uso with-timezone pero tengo
cuidado de poner las constantes con zona numerica explicita (
tipicamente UTC=+00 ) ).


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

Re: [pgsql-es-ayuda] Funcion Postgresql update a SQL SERVER

[Francisco Olarte]

Ruben:

2017-03-20 6:20 GMT+01:00 Ruben avila galindo <ruben2...@gmail.com>:
> Hola amigos queria saber si puedo hacer una funcion en PostgreSQL pero que
> en la funcion actualize una BD de SQL SERVER.

Divide et impera. Primero intenta modificar un SQL server desde
cualquier parte de postgres. Yo para eso miraria de buscar los Foreign
Data Wrappers sobre TDS que hay por ahi. Con eso puedes 'importar' una
tabla de sql server y verla local en postgres. Entonces solo te queda
hacer una funcion que actualize dos tablas en postgres.

Eso si, 
> create function sp_actualizar_stock

Ten en cuenta los disaster-recovery. Cuando manipulas dos BD a la vez
sin un gestor de transacciones global tienes la posibilidad de que
cuando haya problemas se te desincronizen, con lo que deberias tener
un mecanismo para corregirlos. Lo digo concretamente por el nombre
"stock", he tenido algun caso de sincronizar stocks en dos servidores
y aunque era dificil ( has de tener el problema entre que el sistema
hace commit en uno y el otro, la ventana es pequeña ) conseguia tener
discrepancias ( que solucionaba pegando un barrido de las tablas de
vez en cuando ).

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

Re: [pgsql-es-ayuda] migracion de versiones

[Francisco Olarte]

2017-03-16 19:46 GMT+01:00 Maria Antonieta Ramirez <marami...@ulsaneza.edu.mx>:
> Por medio del presente contacto a ustedes
...
> Sin mas por el momento quedo a sus órdenes para cualquier duda o comentario.

( Su es tono quizas excesivamente 'formal' para este contexto. No pasa
nada, es totalmente correcto,  pero nos pone en la tesitura de si
responder en uno similar o utilizar el tono mas relajado habitual en
la lista. )

Dicho esto:

> ya que deseo migrar una base de
> datos en postgres que esta en una version vieja que aun no me dicen que
> version es, la quieren pasar a una version del mismo manejador pero en una
> version mas avanzada podria ser la 9.4 o 9.6.
> Es una base muy grande , tampoco me han dado a conocer el tamaño de la
> misma, Mi duda es si para esto necesito una herramienta de migración o
> bastaria con subir un respaldo a la nueva estructura en la version mas
> actual que decidan ocupar.

Depende de lo que entienda por "respaldo".

Si es una copia elaborada con "pg_dump" este es siempre un metodo
valido ( recuerde que el respaldo debe hacerse con el pg_dump de la
version mas moderna, ya que, p.e., pg_dump-9.6 sabe como volvar una BD
de version 9.0 para luego poder restaurarla, pero pg_dump-9.0 no sabe
que incluir para la version futura 9.6 ).

Si es una copia de los archivos de datos depende de la version. Desde
hace un tiempo exite un programa "pg_upgrade" capaz de actualizar un
directorio de una version a otra, en ocasiones mucho mas rapido que un
ciclo de dump+restore, lo mas facil para ver cual suele ser ir a la
entrada de pg_upgrade en las docs de la ultima version y en la parte
superior de la pagina hay links a todas las versiones anteriores.

De todas formas conviene que se lea las "release notes" desde la
version antigua a la nueva, para ver si existen problemas.

Dicho esto, sobre todo si va a cambiar de servidor, yo le recomendaria
un dump+restore, con el dump en formato custom ( -Fc ). El restore se
puede acelerar mucho configurando adecuadamente el servidor ( p.e.,
como es una BD nueva no necesita crash recovery, por lo que se puede
usar fsync=off, wal_level minimal y toda una serie de cosas para
acelerarlo, nosotros lo acemos asi, tenemos un
postgres.conf.fast_restore que ponemos en esos casos ). Ademas con ese
formato se puede restaurar por partes ( lease la documentacion de las
opciones de lista / tabla de contenidos , -l y relacionadas. Al
pg_restore se le puede dar un archivo que le dice que partes ( y en
que orden ) restaurar, asi como decirle que lo genere para toda la BD.
Jugando con eso nosotros hemos conseguido restaurar algunas BD
problematicas ( sacamos el archivo, lo partimos, y ejecutamos entre
los trozos scripts SQL para arreglar problemas ). ).

Atentamente.
Francisco Olarte.



>
>
>
>
> Gracias.
>
>

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

Re: [pgsql-es-ayuda] Consulta DBLink

[Francisco Olarte]

Alberto...

Respecto al quoting y dblink, se me escapo el send antes de escribir
que de hecho en el dblink hay  unas funciones dblink_build_* que te
pueden ayudar con tu problema. RTFM as usual.

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

Re: [pgsql-es-ayuda] Consulta DBLink

[Francisco Olarte]

Alberto:

2017-03-18 5:02 GMT+01:00 Alberto Cardenas Cardenas
<alberto.cardenas.c...@gmail.com>:

De dblink no entiendo mucho, pero dado que estas llamando a una function...

>   SELECT  * FROM dblink_exec('base_remota', 'insert into
> public.temporary_test_table (columna) ' || SELECT nombre from curso.tabla1
> limit 1; ||  ' )

Mr da que el problema es que te has liado con la concatenacion de
cadenas. Es decir el segundo argumento esta mal tecleado, el ; esta
donde no debe, la ultima ' esta desapareada.

Te sugeririria que empiezes con un select trim() poniendo el
codigo de montar la consulta remota ahi ( trim o cualquier otra
funcion inofensiva ) hasta que eso te funcione, y entonces pasar al
dblink cuando ya sepas que la consulta esta bien montada.

De hecho te va a costar, porque necesitas que se manden comillas en el
valor ( si nombre es como parece un texto ) que pasas a dblink, con lo
que necesitaras doblarlas al montarlo, de ahi que mejor lo hagas en
dos fases. Yo en estos casos recomiendo una pequeña funcion en pgsql o
similar para poder ir por pasos ( paso uno, sacar nombre, paso 2,
DOBLAR las comiilas en el valor de nombre, paso 3 concatenar el valor
de nombre con el resto del query. La ventaja es que probablemente
encuentres funciones que te ayuden con cosas como las comillas si lees
un poco la documentacion.

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

Re: [pgsql-es-ayuda] error

[Francisco Olarte]

Maria Antonieta:

2017-02-10 18:20 GMT+01:00 Maria Antonieta Ramirez <marami...@ulsaneza.edu.mx>:
> Por medio de la presente pido su ayuda para saber acerca de este mensaje que 
> me aparece...
( Imagen suprimida, hubiera estado bien tener el texto de error en texto )...
> Sin mas por el momentoq quedo en espera de sus comentarios.

Un poquito de jujel dice, en la primer hit para "winsock error 10061"
(https://msdn.microsoft.com/en-us/library/windows/desktop/ms740668(v=vs.85).aspx)
, que el error 10061 es el WSAECONNREFUSED:

WSAECONNREFUSED 10061 Connection refused.

No connection could be made because the target computer actively
refused it. This usually results from trying to connect to a service
that is inactive on the foreign host—that is, one with no server
application running.

Eso viene a decir que el host que recibe la conexion no tiene a nadie
escuchando en ese puerto ( o que tiene algun firewall que lo simula ).
Tipicamente ese te pasa cuando el servidor no esta arrancado o la
cadena de conexion no tiene la direccion correcta del servidor sino la
de otra maquina. Revisa bien todo eso.

Francisco Olarte.



>
>
> Gracias!!!

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

Re: [pgsql-es-ayuda] Cadena con dos puntos

[Francisco Olarte]

José:

2017-01-23 17:56 GMT+01:00 jvenegasperu . <jvenegasp...@gmail.com>:
> Estoy revisando y resulta que php si estaba insertando correctamente la
> información lo que pasaba es que pgAdmin cuando le haces un select * from
> tabla solo muestra el primer renglon. y ni un indicador que el campo tiene
> mas de uno entonces parecia que no se insertaba nada como dices caprichitos
> de pgadmin.
...
> Asi que todo bien solo tengo que limpiar el retorno de carro de la salida
> del del ws y mirar la información con otro cliente que no me genere dudas
> como pgAdmin

Ferpecto. Yo, para mirar cosas, recomiendo siempre un fallback al psql
que incluyen ( que, de hecho, es el unico que uso y llevo con el
postgres desde antes de que fuera SQL ). Cuando estes mirando poco s
registros usa '\pset expanded', que se ven muy bien. Y, si tienes
dudas, tira de un \copy y metele un 'od -tc -tx1' al resultado ( o usa
tu editor favorito con modo hex )

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

Re: [pgsql-es-ayuda] Cadena con dos puntos

[Francisco Olarte]

Buenos dias:

2017-01-23 16:24 GMT+01:00 jvenegasperu . <jvenegasp...@gmail.com>:
> insert into
> cdrs.errores_sunat
> (faultcode,faultstring,invoice_type_code,s_num,ambiente,lado,metodo)
> values ('.200',$$ Detalle: Failed to establish a backside
> connection$$,'RA','FF14-1','beta',':Serve','getStatus');

La parte problematica al menos parece no dar problemas:


n=> values ('.200',$$ Detalle: Failed to establish a backside
connection$$,'RA','FF14-1','beta',':Serve','getStatus');
 column1 |   column2   |
column3 | column4 | column5 | column6 |  column7
-+-+-+-+-+-+---
 .200|  Detalle: Failed to establish a backside connection | RA
  | FF14-1  | beta| :Serve  | getStatus
(1 row)

> 1.- Cuando intento guardar con pgadmin o php con el espacio en blanco al
> inicio guarda todos los campos excepto este campo y no me devuelve ningun
> error
> 2.- Cuando quito el espacio al inicio de la cadena he intento guardar con
> pgadmin si me guarda el campo

Eso tiene toda la pinta de ser caprichitos de pgAdmin, no lo us nunca,
pero es posible que si pones que version (de pgAdmin) usas ( ya que si
no recuerdo mal acaban de sacar una nueva ) alguien te pueda ayudar.

> 3.- Cuando quito el espacio al inicio de la cadena he intento guardar con
> php solo me guarda "Detalle:" y se corta donde empieza los dos puntos

Eso tiene toda la pinta de que el PHP te este usando, en su subsistema
de base de datos, los : como marcador de campo a sustituir por nombre.
No estoy familiarizado con el, pero en las docs estara y cosas como
esas pasan en muchas API.

En general, desde un programa, NUNCA uses una cadena con el query
completo, usa sustituciones, cosas tipo execute('insert into
cdrs.errores_sunat
(faultcode,faultstring,invoice_type_code,s_num,ambiente,lado,metodo)
values (?,?,?,?,?,?)',
'.200',
"Detalle: Failed to establish a backside connection",
'RA','FF14-1','beta',':Serve','getStatus')

La sintaxis exacta variara con el lenguage / requester que uses, pero
todos lo soportan, y ademas si tienes las cosas en variables como
suele pasar es mucho mas comodo (execute($query, $v1, $v2, ), RTFM
for details pero seguro que se puede ).

> Quitar el espacio al inicio me supone menos espacio usado por el registro y
> se soluciona con un trim.
> Sin embargo desde php me corta la cadena hasta los dos puntos alguien me
> podria indicar como podria grabar esa cadena incluido los dos puntos y me
> queda la duda no se puede insertar en postgres una cadena que empieza con
> espacio en blanco?

Si que se puede, tu problema parece ser de los programas clientes que
usas. Usando uno sencillito ( el psql que viene incluido ):

n=> create temporary table t (v varchar);
CREATE TABLE
n=> insert into t values (' '), ($$ $$), (' $$ $$ '), ($$ ' ' $$);
INSERT 0 4
n=> select '<'||v||'>', length(v) from t;
 ?column?  | length
---+----
 < >   |  1
 < >   |  1
 < $$ $$ > |  7
 < ' ' >   |  5
(4 rows)

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

Re: [pgsql-es-ayuda] ejecutar script linux con clave

[Francisco Olarte]

Carlos:

Reformateo un poco porque el top-posting hace dificil entenderse.

>> 2017-01-04 16:20 GMT+01:00 Carlos Edward Grajales Marmolejo
>> <cgraja...@colombiasoftware.net>:
>> > Considero que si es un cron, y si este lo ejecuta el root de la maquina,
>> > lo
>> > mas rapido es usar el .pgpass, configurado en la carpeta del root, ahi
>> > se
>> > especifica el usuario, clave, puerto y host de comunicacion. De esa
>> > manera
*
>> > no hay que hacer configuraciones adicionales.

>>
>> El .pgpass especifica el PASS para una combinacion ( con posibles
>> comodines ) de host/usuario/bd/..
2017-01-04 20:15 GMT+01:00 Carlos Edward Grajales Marmolejo
<cgraja...@colombiasoftware.net>:
> Yo uso el esquema del pgpass para hacer copias de seguridad, y otros
> procesos automaticos que requieren de comunicacion a la base de datos via
> Shell

Como yo.

> El formato del .pgpass es este:
> hostname:port:database:username:password
> La documentacion esta en esta ruta.
> https://www.postgresql.org/docs/9.2/static/libpq-pgpass.html

Exactamente lo que digo.

> Asi es que es suficiente el .pgpass para realizar una comunicacion efectiva
> via consola a postgres sin especificar la clave , ideal para un crontab que
> use el shell o un psql -U x -h zz  donde x y zz estarian
> especificados en en el .pgpass

Esos -U -h  SON configuraciones adicionales. No tienen porque estar en
el .pgpass, ya que, segun ponen en tu link:
" Each of the first four fields can be a literal value, or *, which
matches anything. "

Lo que yo intentaba indiar es que para mantener la configuracion
INCLUIDA EN EL SCRIPT al minimo se use el "service file", ya que es
muy habitual tener un monton de scripts que usan los mismos parametros
para host/port/db e incluso a veces user. Todo esto lo metes ahi, y en
el pgpass metes la pass, que no se puede meter en el service file por
problemas de seguridad ( de forma similar a como tienes el
password/shadow en los unix ).

Francisco Olarte.

P.S.: A que es mas facil leer las cosas cuando van en orden, y ademas
suprimo las cosas redundantes, como las copias de tu firma?

FO

-
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] ejecutar script linux con clave

[Francisco Olarte]

Carlos:

2017-01-04 16:20 GMT+01:00 Carlos Edward Grajales Marmolejo
<cgraja...@colombiasoftware.net>:
> Considero que si es un cron, y si este lo ejecuta el root de la maquina, lo
> mas rapido es usar el .pgpass, configurado en la carpeta del root, ahi se
> especifica el usuario, clave, puerto y host de comunicacion. De esa manera
> no hay que hacer configuraciones adicionales.

El .pgpass especifica el PASS para una combinacion ( con posibles
comodines ) de host/usuario/bd/..

Para especificar el host se usa el pg_service.conf (
https://www.postgresql.org/docs/9.6/static/libpq-pgservice.html ) , en
donde se pone todos menos las pass ( y que no tiene porque estar
protegido ).

Una vez configurados los dos se selecciona el servicio por la variable
de entorno PG_SERVICE o, alternativamente, poniendo service= como
nombre de base de datos. Funciona muy bien.

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

Re: [pgsql-es-ayuda] Ayuda postgresql

[Francisco Olarte]

Henry:

2016-12-09 15:44 GMT+01:00 Henry Anchante <hacat...@fedoraproject.org>:
> Señores buenos días mi consulta es la siguiente, como voy a postgresql lo
> bajo directo o hay que pagar una suscripción, o tengo que buscar un
> proveedor que me de servicio.

Te lo bajas de www.postgresql.org, mas o menos.

Dependiendo de tu SO puede que haya versiones precompiladas, o que te
lo instale directamente su gestor de paquetes ( tipico de las distros
de Linux y similares ).

Es totalmente libre y gratis, bajatelo y ya esta.

Hay proveedores que te dan servicio si no quieres liarte a
instalartelo, y algunas versiones con extras y demas.

Y, si entiendes ingles, leete el manual aunque sea por encima que vale
la pena ( no se decirte si hay versiones en español, siempre uso el
original ).


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

Re: [pgsql-es-ayuda] Ayuda postgresql

[Francisco Olarte]

2016-12-07 18:03 GMT+01:00 jvenegasperu . <jvenegasp...@gmail.com>:
...
> te referies con budines porque para mi budin es un postre y ya me dio hambre
> El 5 de diciembre de 2016, 18:04, Henry Anchante
>> Hola amigos necesito saber como adquirir en Perú la bd o si existe alguien
>> que quiera ver postgresql para un budines.

Lo siento por el quote feo, pero es lo que pasa cuando la gente hace
top posting.

 que se refiere a un bisnes ( business, seria, y si en España
tenemos ASDF supongo que en Peru casi seguro que tambien ). ( y la
doble transposicion tuya en referies, supongo que por refieres, es de
ir rapido ).

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

Re: [pgsql-es-ayuda] Cambio en tipo de columna de varchar por text

[Francisco Olarte]

UN poco liado, pero es lo que pasa cuando se hace bottom quoting

2016-11-02 19:23 GMT+01:00 Ivan Perales M. <ivan.pera...@gmail.com>:
...
> ellas, ademas manejo varias schemas, por lo que potencialmente si habria
> miles de alters, entonces si tendria que hacer un vacum a la tabla que
> mencionas por seguridad.
> 2016-10-30 9:14 GMT-06:00 Jaime Casanova <jaime.casan...@2ndquadrant.com>:
...
>> el peor efecto que habrá es un update en pg_attribute por cada alter
>> table (lo que significa un registro muerto por cada alter table) si
>> son muchas tablas quizá un vacuum (normal no full) sobre pg_attribute
>> cada tantas tablas pero esto solo si hablamos de miles de alter table.

Aunque lo optimo puede ser deshabilitarlo, hacerlo manual durante el
proceso y rehabilitarlo al final, recuerda que, salvo que lo hayas
quitado, esta el autovacuum, que, si no recuerdo mal, tambien opera en
las tablas de sistema ( con lo que aunque no te las deja igual de bien
si que te las mantendra a raya ).

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

[pgsql-es-ayuda] Re: [pgsql-es-ayuda] Re: [pgsql-es-ayuda] Re: [pgsql-es-ayuda] Re: [MASSMAIL] [pgsql-es-ayuda] Re: [pgsql-es-ayuda] Guía para configuración óptima de Postrgesql

[Francisco Olarte]

2016-10-26 19:46 GMT+02:00 Juan Manuel Acuña <gps...@gmail.com>:
> Muchas gracias!!! el sitio está súper interesante. De la herramienta que
> mencionas no la conozco, la voy a buscar, y si la encuentro la pongo por
> acá.

Antes de ejecutarlas y ponerlas verificad que son adecuadas para las
versiones mas o menos recientes, ya que circulan cosas por ahi que
estan totalmente obsoletas y que proporcionan consejos directamente
dañinos.

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

[pgsql-es-ayuda] Re: [pgsql-es-ayuda] Guía para configuración óptima de Postrgesql

[Francisco Olarte]

Buenas tardes:

2016-10-25 16:44 GMT+02:00 Juan Manuel Acuña <gps...@gmail.com>:
> Alguien me podrá recomendar alguna página o guía para optimizar la
> configuración de Postgresql en un servidor linux Debian?

Asi, con todos los detalles que das, poco mas que
https://wiki.postgresql.org/wiki/Performance_Optimization y  los
capitulos relevantes del manual.

Lo siento, todo en ingles, pero yo tiro siempre de la version original si puedo.

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

Re: [pgsql-es-ayuda] Convertir de integer a text

[Francisco Olarte]

Ivan:

2016-10-21 23:07 GMT+02:00 Ivan Perales M. <ivan.pera...@gmail.com>:
> Debo convertir una columna de tipo integer a tipo text por que se requieren
> valores alfanuméricos, la base de datos actualmente tiene alrededor de 50
> mil registros. La pregunta es, si despues de convertirla debo ejecutar algun
> tipo de proceso como para sanear el cambio? o lo hace el autovacuum que se
> ejecuta diariamente?

50k registros no son demasiados, el autovacuum te deberia dejar las
cosas ordenaditas.

No obstante ese es el tipo de cambio que reescribe toda la tabla, con
lo que tienes todos los boletos para que te queden muchos agujeros (
espacio libre en el archivo de la tabla, que se ira arreglando con el
tiempo si hay modificaciones en la tabla con el autovacuum ) y dado
que no es muy grande ( salvo que sean filas monstruosas ) es el tipico
cambio que te puede interesar ejecutar desactivando el autovacuum de
la tabla temporalmente y haciendo un vaccuum full manual ( algo como
alter table set autovacuum_enabled=false, alter columna, vacuum full
verbose analyze, set autovacuum_enabled true ) ya que de todas maneras
tendras que programar una ventana de mantenimiento para cambiarla (
ademas el autovacuum en esa tabla no hara mucho mas que incordiarte
durante el cambio ).

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

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

[Francisco Olarte]

Manuel:

2016-10-18 17:10 GMT+02:00 Manuel Aller <manuel.al...@infracoop.com.ar>:
> Los pasos para hacer la migración son:
> 1. cambiar el archivo de configuración para que diga:
> data_directory = '/database/pgdata'
> 2. detener el servicio de postgres:
> # sudo service postgresql stop

Probablemente funciona sin problema, pero yo en general recomendaria
siempre invertir esos pasos, no tocar nada con el servicio en marcha
si lo vas a parar.

> 3. hacer que el nuevo directorio sea del user postgres:
> # sudo chown -R postgres.postgres /database/pgdata

Salvo que lo hagas para minimo downtime, en cuyo caso esto deberia ir delante.

> 4. mover los datos al nuevo directorio:
> # mv /var/lib/postgresql/9.3/main /database/pgdata

Y para hacer ese paso necesitaras estar corriendo como usuario
postgres o root ( que con el nivel de detalle que lo cuentas conviene
añadirlo por dejarlo completo del todo ).

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

[pgsql-es-ayuda] Re: [pgsql-es-ayuda] Actualizar versión de PG

[Francisco Olarte]

2016-10-11 19:15 GMT+02:00 Herman Estaban <hermanesta...@gmail.com>:
> Hola a todos, tengo poco tiempo utilizando PG, instale la versión 9.5 y
> quisiera actualizar a la ultima versión 9.6, que debo hacer?

Decirle a tu encargado de actualizar Postgres 'Actualizame a la version 9.6.'

Ahora en serio, dar algunos detalles de que te has instalado y como
para que alguien familiar con la combinacion te pueda decir algo. Por
lo que yo se, lo de arriba puede ser correcto.

En general suele ser cuestion de ejecutar pg_upgrade, previo backup si
los datos son importantes. O, si el servidor es pequeño, puede que
mejor pg_dump/pg_restore si quieres reorganizar alguna cosilla, pero
siendo nuevo lo dudo. La documentacion oficial cuenta como se hace
todo, eso si, en Ingles ( no se si existe una version en castellano,
yo habiendo una original en ingles siempre tiro de ella ).

La unicas recomendaciones genericas que se me ocurren, haz los backups
en -Fc de cada BD y uno de globales con el pg_dumpall, recuerda que
siempre se hacen backups con la version mas reciente del pg_dump ( y
que el pg_upgrade a usar es el mas reciente, si lo piensas es logico,
los programas de la 9.6 saben como era la 9.5, los de la 9.5 ni sabian
si iba a existir la 9.6 ).

En resumen, repito, da detalles porque sino poco se te puede decir.

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

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

[Francisco Olarte]

Buenas tardes:

2016-10-07 23:15 GMT+02:00 Electricos del Valle S.A. - Jose Fdo Donado
E. <jfdon...@electrovalle.com>:
>
> 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.

En general, cuando he hecho cosas similares en Linux lo mas seguro
suele ser parar el server ( aprovechando que muchas veces tienes que
hacerlo para instalar los discos nuevos ), copia del unico directorio
en el que estan los datos y rearranque tras ajustar el .conf. O cuando
he cambiado un disco de datos por uno nuevo montarlo en el path del
anterior y copia.

Pero vamos, sin saber como eran tus discos, como son ahora y donde
estan los binarios y datos en tu instalacion, poco se puede decir.

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

Re: [pgsql-es-ayuda] campos timestamp

[Francisco Olarte]

Hola Hellmuth...

2016-10-06 14:54 GMT+02:00 Hellmuth Vargas <hiv...@gmail.com>:
> 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

Y el resultado fue? porque no lo tengo muy claro. Con las zonas
p*t**ndo de por medio puede que no obtengas el mismo resultado siempre
( aqui utilizas TEXTO, eso es facil, no TSw/TZ, que es lo que pedia el
ejemplo original ).

Mira lo que pasa en mi maquina si cambio las constantes de texto a
timestamp with time zone, como en el ejemplo original:


n=> 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 ;
fecha|hora |  fechahora
-+-+-
 1968-09-08 00:00:00 | 1900-01-01 10:00:00 | 1968-09-08 10:00:00
(1 row)

n=> select cast('1968-09-08 00:00:00+01'::timestamp with time zone as
timestamp) as fecha,cast('1900-01-01 10:00:00+00'::timestamp with time
zone as timestamp) as hora, cast('1968-09-08 00:00:00+01'::timestamp
with time zone  as timestamp)+cast(cast('1900-01-01
10:00:00+00'::timestamp with time zone as timestamp) as time) as
fechahora;
fecha|hora |  fechahora
-+-+-
 1968-09-08 00:00:00 | 1900-01-01 09:45:16 | 1968-09-08 09:45:16
(1 row)

Siempre hay conversion de tipos, no hay que olvidar nunca que un
TSw/TZ internamente no es un bonito texto y NO TIENE LA ZONA HORARIA
ALMACENADA ( lo que es evidente si se miran los requisitos de
almacenamiento, que son los mismos para w/ que wo/ TZ ). Internamente
equivalente a un numero real gordo, un punto en la recta del tiempo.
La diferencia es que cuando lo imprimes si es w/TZ el sistema lo
imprime en la TIME ZONE activa en ese momento, mientras que si es
WO/TZ te imprime el equivalente a la zona UTC. Por eso cuando se
quieren guardar 'horas locales', es decir, la hora como la veia el
usuario, hay que guardar dos cosas, la zona del usuario y un timestamp
( este ultimo puede ser w/ o WO/, normalmente es mas facil wo/ pero
ambos valen ).

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

Re: [pgsql-es-ayuda] campos timestamp

[Francisco Olarte]

omo yo estoy en Madrid el sistema me pinta que
hora era en Madrid en ese instante.

Espero que te ayude, de aqui coge lo que te valga, intenta algo,
pregunta si tienes mas dudas, recuerda que solo TU sabes exactamente
como llegaron a tu BD esas columnas y como desenredarlas.

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

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

[Francisco Olarte]

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.

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

Re: [pgsql-es-ayuda] Problema con pgbench-tool

[Francisco Olarte]

Lazaro..

2016-09-29 18:38 GMT+02:00 Lazaro Garcia <lazaro3...@gmail.com>:
> Pero entonces no debería ser eso un bug de pgbench-tools??

Con esto del top-posting no tengo muy claro que es 'eso', pero es
posible que lo sea. No uso pgbench-tools, pero parece ser una
herramienta potente y compleja, y tener una serie de parametros
configurables que no sabemos como has configurado. Ese tipo de error
podria estar perfectemente generado porque en algun sitio tenias que
configurar VAR=entero y lo has dejado como VAR=, p.e.

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

Re: [pgsql-es-ayuda] Problema con pgbench-tool

[Francisco Olarte]

2016-09-29 17:51 GMT+02:00 Lazaro Garcia <lazaro3...@gmail.com>:
> Buenos días a todos. Estoy intentando realizar unas pruebas a la base de
> datos con pgbench-tools y mientras se está ejecutando el test estoy viendo
> este error constantemente:
> ERROR:  invalid input syntax for integer: ""
> LINE 1: ...e,dbsize,rate_limit) values('select.sql','16','1','','100','...
> Saben a qué se deba.

Sin mas contexto ( como la linea completa, o los comandos que ejecuta
) dificil, pero tiene toda la pinta de que ese '' entre el 1 y el 100
debe ser un entero, y que aunque pg convierte texto a casi cualquier
cosa, enteros incluidos, una cadena vacia no es un entero valido.

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

Re: [MASSMAIL]Re: [pgsql-es-ayuda] pg_dumpall desde maquina remota

[Francisco Olarte]

Gilberto:

2016-09-20 19:29 GMT+02:00 Gilberto Castillo <gilberto.casti...@etecsa.cu>:
> No he seguido el hilo detenidamente, pero recuerden que el permiso debe
> ser para el usuario que ejecuta el pg_dump sobre la carpeta dada.
> Ejemplo para usuario postgres.
> $ sudo chown postgres:postgres -R /mi_carpeta_de_backup

Mejor sin -R, salvo que este haciendo cosas muy raras.

Y si la carpeta de backup, en general, vale para mas cosas, es
peligroso, lo mejor es testear sin mas si puede escribir en ella (
echo > /capetadebackup/tst es suficiente )

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

Re: [pgsql-es-ayuda] pg_dumpall desde maquina remota

[Francisco Olarte]

2016-09-20 18:24 GMT+02:00 Gerardo Herzig :
> Que pasa si lo sacas por STDIN?

STDOUT para sacarlo.

-
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] pg_dumpall desde maquina remota

[Francisco Olarte]

Abel:

2016-09-20 14:17 GMT+02:00 Abel Osorio <abel.m.oso...@gmail.com>:

> Una última cosa, y acá puedo estar diciendo cualquier cosa... ya me
> corregirán. En -f ARCHIVO, ARCHIVO es local o remoto? Probaría, sólo por las
> dudas, cambiar el -f por >, es decir:
> pg_dump dbdatos -h 192.168.1.1 -U prueba -s -f /tmp/DBdatos.sql
> pg_dump   dbdatos -h 192.168.1.1 -U prueba -s > /tmp/DBdatos.sql
> Con eso te aseguras que el archivo se va a crear localmente.

Es local, el pg_dump es un programa en C que usa sin mas la libpq para
conectarse al servidor remoto. Ante la duda, con estas cosas, mira los
fuentes.

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

Re: [pgsql-es-ayuda] pg_dumpall desde maquina remota

[Francisco Olarte]

2016-09-20 13:37 GMT+02:00 Kernel <jucab...@gmail.com>:
...
> el usuario es prueba, tanto en el sistema como en la base de datos.

Perfecto, otra cosa descartada.

> La red va bien, esto funciona bien
>  psql dbdatos -h 192.168.1.1 -U prueba  (ok sin problemas no pide password )

Si, eso es lo que mas mosquea..

> debe de ser algo de permisos

, ahora que lo dices, que pasa si haces un 'dd if=/dev/zero
of=/tmp/DBdatos.sql count=xxx'

( sustituye xxx por el tamaño aproximado que crees que va a tener el
backup en kilobytes )

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

Re: [pgsql-es-ayuda] pg_dumpall desde maquina remota

[Francisco Olarte]

Solo una nota:

2016-09-20 9:52 GMT+02:00 Kernel <jucab...@gmail.com>:

Tu copia editada no muestra el usuario del sistema con el que estas
ejecutando y
> He probado a crear el fichero /home/prueba/.pgpass , con permisos 600, pero
> nada
> 192.168.1.1:5432:dbdatos:prueba:prueba

, el .pgpass tiene que estar en $HOME/.pgpass ( lo digo porque mas de
uno confunde db-user con os-user , y no tenemos forma de saber por lo
que mandas si ese es tu caso ).

¿ Has comprobado que las conexiones llegan desde la IP que esperas
(con algun netstat, ip route y/o tcpdump ) ? ( y no se si ademas
necesitas que resuelvan en inverso, eso lo deberias mirar tambien ) Y
otra cosa, ¿ es lo que has puesto el pg_hba completo ? ( piorque
parece que el post esta editado ).

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

Re: [pgsql-es-ayuda] Estructura tipo diccionario o hashset

[Francisco Olarte]

Hola José:
2016-08-26 14:07 GMT+02:00 José Hurtado <jhurta...@gmail.com>:
> No uso java, soy de C# y javascript, el nombre de la estructura es lo de
> menos, en el título puse "diccionario" o hashset porque buscaba la
> funcionalidad k-v, llamémosle KEYVALUE o DIC o XXX.

Disiento. El nombre de las cosas transmite mucho, si quieres un
diccionario y lo llamas conjunto vamos mal. De hecho ningun lenguaje
que use llama set a los diccionarios. Otra cosa es que por motivos
historicos se ha extendido, desde el perl la costumbre de llamar
hashes a los diccionarios ( el perl fue de los primeros en llamarlos
asi en partes extensas de la documentacion, si no recuerdo mal ), lo
que ha llevado a que la gente piense que hash implica K,V, pero no es
asi es map o dict lo que implica k,v, set implica k, y es un problema
mucho mas facil de abordar.

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

Re: [pgsql-es-ayuda] Estructura tipo diccionario o hashset

[Francisco Olarte]

José:

2016-08-26 10:59 GMT+02:00 José Hurtado <jhurta...@gmail.com>:
> He probado con json y jsonb, el incoveniente es que son valores inmutables y
> una vez que has creado un json es dificil agregarle mas propiedades, hasta
> la versión 9.5 no hay funciones para agregar o eliminar una propiedad
> incluso devolviendo una nueva instancia.

Efectivamente, pero mucho codigo se las arregla con valores inmutables
para las cadenas, p.e. ( Java, perl hasta hace poco, python si no
recuerdo mal ) con lo que para esto te podrian servir, dependiendo del
use case.

> Para resolverlo agregué la extensión plv8, que es el motor v8 de javascript
> de Chrome (https://github.com/plv8/plv8) pero creo que hay una pequeña
> penalización en la conversión de tipos que haciendo muchas llamadas se llega
> a notar en el rendimiento..

Aqui entra lo que decia yo, no se si el problema que tienes es que si
necesitas diccionarios deberias usar un lenguaje que los tenga, como
perl, tcl, python o v8, para la funcion completa, no solo para
implementar el hashset. Cuando llegas a desarrollar algo que necesita
diccionarios en pl/pgsql me da la impresion de que estas empezando a
salirte de los limites para los que se diseño.

...
> Mi propuesta va en el sentido de evitar ese salto de lenguaje que implica
> una conversión de tipos usando una estructura de datos básica en muchos
> lenguajes y util para resolver ciertos algoritmos.

Tanto como basica, un diccionario es de las mas complejas, aunque
venga de serie en muchos.


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

Re: [pgsql-es-ayuda] Estructura tipo diccionario o hashset

[Francisco Olarte]

José:

2016-08-26 10:50 GMT+02:00 José Hurtado <jhurta...@gmail.com>:
> No describo que es un hashset o diccionario porque asumo que los que no lo
> conozcan y tengan interés podrían encontrar mucha información en Internet.

Dejando aparte el como te contestaron o no, repito un SET es un
CONJUNTO, valores unicos, sin claves. Un diccionario en java se llama
MAP, y es una asociacion de claves unicas a valores cualesquiera (
matematicamente todo diccionario es un conjunto de pares k,v, pero no
del todo si te deja mover v ( aunque se podria ver como un borrado mas
insercionen el conjunto ), y ademas no te deja meter (k1,v1)(k1,v2),
que en un conjunto irian bien ).

Lo de que sea hash, tree o skiplist o sorted list es un detalle de
implementacion ( Java, que ya se cito, utiliza p.e. listas
desordenadas para pequeños conjuntos en algunas variantes ).

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

Re: [pgsql-es-ayuda] Estructura tipo diccionario o hashset

[Francisco Olarte]

2016-08-24 14:16 GMT+02:00 Jaime Casanova <jaime.casan...@2ndquadrant.com>:
> 2016-08-24 6:52 GMT-05:00 José Hurtado <jhurta...@gmail.com>:
>> Creo que vendría bien tener algo parecido a:
>>
>> DECLARE
>>   dic1 HASHSET(varchar, schema_name.table_name);
>>   -- format: HASHSET(anytype, anytype)
>>   ...
>> BEGIN
>> ...
>>   ...
>>   IF (hashset_has_key(dic1, "alfa") THEN
>> dic1["alfa"] := (val1, val2)::schema_name.table_name;
>> -- O: hashset_update(dic1, "alfa", (val1,
>> val2)::schema_name.table_name);
>>   ELSE
>> hashset_add(dic1, "alfa", (val1, val2)::schema_name.table_name);
>>   END IF;
>>   ...
>>   hashset_remove(dic1, "alfa");
> Podrías por favro fingir que no todos somos expertos es Java (o al
> menos creo que esa construcción es de Java o no?) e indicarnos que
> haría ese HASHSET ?


Tampoco creo que el OP lo sea (experto en). Parece que lo que quiere
es un diccionario, mapa en java, con claves de tipo varchar.
Normalmente un SET es un conjunto, es decir, solo claves, y el hash es
un detalle de implementacion, puestos a pedir deberia pedir un
diccionario cualquiera. Ademas parece que lo quiere tipo generic de
java/ template de c++. Malamente se va a poder hacer de una forma
facil.

De todas formas, teniendo jsonb, y sus funciones row_to_json y demas
deberia poder hacer lo que quiere sin problemas, un pelo mas largo,
pero con 4 funciones de apoyo le saldria.

Igual tiene mas suerte preguntandolo en -hackers, pero desde luego
este tiene toda la pinta de un http://xyproblem.info/ unido a una mala
eleccion de lenguage (plperl/plpython/pltcl parecen mejores si
necesita ese tupo de cosas) o de sitio en el que meter la logica.

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

[pgsql-es-ayuda] Re: [pgsql-es-ayuda] disable triggers dentro de una función afecta a la conexión actual o todas

[Francisco Olarte]

Mauricio:

2016-08-10 16:52 GMT+02:00 mauricio pullabuestan <jmaurici...@yahoo.es>:
> Tengo varias tablas que tiene un trigger que concatenan datos para 
> ingresarlos en otra tabla.
> En algunas funciones hago update masivos a estas tablas pero no necesito que 
> el trigger se ejecute

No necesitas o no quieres que se ejecute?

> Al ejecutar la función que desactiva el trigger y mientras dura la ejecución, 
> los triggers están desactivados solo para esta conexión o para todas las 
> conexiones?
> Si los triggers están desactivados para todas las conexiones existe alguna 
> manera de decir, quiero desactivar los triggers solo para esta conexión?

Has probado a jugar con el session_replication_role y con el
DISABLE/ENABLE [ REPLICA | ALWAYS ] TRIGGER ?

Esta pensado para cosas similares, en sistemas de replicacion marcas
determinados triggers para que se activen en el origen y otros ( o
ningunos ) en la replica, y con el session_replication_role dices que
eres, asi si tienes triggers que actualizan otras tablas te los saltas
en la replica, ya que la replicacion te mandara las actualizaciones de
todas formas. Tambien puede ser util para casos como bulk-loading en
los cuales puedes calcular y cargar de golpe los datos basicos y los
calculados pro el trigger de forma mucho mas eficiente.


Echale una mirada al ALTER TABLE y al setting ese.

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

Re: [pgsql-es-ayuda] [OFF-TOPIC] UBer cambia Postgres por MySQL

[Francisco Olarte]

On Thu, Aug 4, 2016 at 8:59 PM, Edwin Quijada
<listas_quij...@hotmail.com> wrote:
> He leido este articulo sobre como Uber cambio a Mysql desde postgres , Alvaro 
> y Jaime me gustaria oir su opinion acerca de lso puntos que ellos enumeran 
> aqui para el cambio de PG.

Hay ademas una cosa fundamental ademas, que lo que hacen es cambiar
XXX(no lo dicen) + Pg por YYY(no lo dicen)+ZZZ(silo dicen, un
middleware suyo que no recuerdo como se llama)+MySql.

Esta bien leerse los comentarios, casi todos en ingles, que ya te han
comentado, pero lo del technical reasoning es muy incompleto porque se
callan montones de cosas ( las que dicen son ciertas en su mayoria, no
es que mientan ).

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

Re: [pgsql-es-ayuda] hash

[Francisco Olarte]

2016-07-27 14:12 GMT+02:00 Guillermo E. Villanueva <guillermo...@gmail.com>:
> Hola Edwin, con la prueba que hice me quedé tranquilo, el día que lleguen a
> mas de 50 millones de registros yo y mis hijos ya estaremos jubilados jaja.
> No reemplazo nada, simplemente trunco el md5(). Tengo un trigger que hace lo
> siguiente:
> new.columnahash := right(md5(new.columnaid),13);

Ten en cuenta que las matematicas son muy putillas, y despues de 50
millones de unicos te pueden venir 3000 colisiones.

De todas formas la probabilidad de colision ahi es la clasica paradoja
del cumpleaños, y con 3 digitos hexadecimales y 50 millones de
intentos esta en un 25% ( Aqui mi codigo, que seguro tiene algn
problema, y que calcula la probabilidad de NO colision, que como casi
todo el mundo sabe es la facil:

$ perl -e '$x=16**13; $p=1; for (1..50_000_000) { $p*=$x-$_; $p/=$x; }
print "$p\n"'
0.757633315718648

Seguro que tiene errores de redondeo y cosas asi, y creo que lo que
calculo es para 50M+1, pero bueno, sus haceis una idea )

Yo probaria a usar base 64, parece que no pero cambiando 16 por 64 en
ese codigo da un resultado de 0.631153 ).

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

Re: [MASSMAIL] Re: [pgsql-es-ayuda] Fwd: Actualizar o insertar datos en postgres de SQL Server

[Francisco Olarte]

Mario:

2016-07-14 18:12 GMT+02:00 Mario Soto Cordones <marioa.soto.cordo...@gmail.com>:
...
> Quizá cuando algún día se cree una organización (si es que ya no está) que 
> certifique en PostgreSQL (estándar), muchos tomaríamos alguna certificación 
> en PostgreSQL.

Eso tiene varios graves problemas. Uno es que el conocimiento de PG es
en cierta medida perecedero. Otro es como lo pones. Me explico, puedes
ponerlo, p.e., tan duro como 1 curso completo de universidad? X
creditos ? Y habra gente que lo saque pero no demuestre demasiado.

Easa certificaciones, en mi opinion, son solo validas, como apuntabas,
si van acompañadas de una serie de referencias/experiencias/curriculum
y demuestran una cierta evolucion temporal. Per se no demuestran
mucho. Yo tengo, a modo de ejemplo, unos cuantos cursos de radio y
ondas electromagneticas aprobados durante la carrera. Y tras
aprobarlos sabia un monton. Pero tras 30 años sin usarlo me quedan
solo las nociones mas generales ( mas una capacidad de aprenderlo, si
lo necesito, mas rapido que un profano, algo queda siempre ). O en
otro lado, tras usarlo desde que sacaron el 1.0 a mediaos de los
ochenta yo sabia muchisimo de windows en el 2001, pero tras conseguir
microsoft echarme definitivamente a golpe de "putaditas" con el XP,
que fue la paja que quiebra el lomo del camello, actualmente no se
manejar el windows 10.

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

Re: [MASSMAIL] Re: [pgsql-es-ayuda] Fwd: Actualizar o insertar datos en postgres de SQL Server

[Francisco Olarte]

Mario:

2016-07-14 17:27 GMT+02:00 Mario Soto Cordones <marioa.soto.cordo...@gmail.com>:

...
> Ahora bien, a título muy personal (y por favor mi intención no es armar
> polémica ni nada por el estilo):
...
> -  La mejor certificación es la que te pueden dar tus clientes
...
> En lo personal para mi esa es la mejor certificación.

El problema con esas certificaciones es que eso es mas 'pedir
referencias', que tiene un problema. Si le dices a un futuro
contratante que lo haga, puede no tener ganas. Aunque las tenga, la
informacion util que se transmite en las referencias depende del grado
de conocimientos del empleador anterior y el nuevo. Igual que cuentas
esto:

> Cómo anécdota: Durante muchos años trabajé como DBA de Oracle, y conocí
> otros DBA Certificados por Oracle y créanme muchas veces no estaban a la
> altura del certificado que poseían

A mi me ha pasado repetidas veces de llegar a un sitio, presentarme al
super-genio-master-del-universo en xxx al que iba a ayudar y darme
cuenta de que no tenia ni papa de idea, era simplemente un buen gestor
de su imagen que sabia algo mas que el jefe.

Como nota por otro lado, "a la altura del certificado" suelen estar,
lo que pasa es que lo que te garantiza el certificado es muy poco, y
sobre todo demuestra capacidad de pasar una serie de examenes en un
momento del pasado, pero hay gente que no pasa de ahi.

> Con esto no quiero decir que no te certifiques, esa siempre será tu opción,

Tampoco quiero decir yo que se certifique, pero el certificado, al
igual que un titulo universitario, tiene un significado estandarizado.

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

Re: [pgsql-es-ayuda] funcionamiento de temp_buffer

[Francisco Olarte]

José:

2016-07-11 1:49 GMT+02:00 jvenegasperu . <jvenegasp...@gmail.com>:
> tomando en cuenta lo que decia Francisco revise el tamaño de todas las
> tablas involucradas y le di a temp_buffers la suma del tamaño de tabla 1,
> tabla 2 y tabla 3 con el resultado del tamaño del join.
> y de nuevo todo se ejecuta como antes.
> son las primeras pruebas pero incluso diria que hasta esta andando mas
> rapido.

Es posible que te sobre un poco mas de RAM y acelere. De todas formas...

> tengo 2 bases de datos con algunos miles de registro en un primer caso
> necesite temp_buffers a 15 megas y en el otro temp_buffer llego a 76 mb. que
> es el tamaño que suman t1,t2 y t3 en cada caso
>
> Gracias ahora nuevamente todo esta andando bien aunque un me pregunto como
> actuaria si la BD fuera mas grande y no me alcanzara la memoria.

Ya te han sugerido la solucion rapida, compra RAM ( temp_buffers no se
usa si no se pide, con lo que si tu funcion brutal va en sesiones
contadas no pasa nada, pero si va en muchas, ojito ).

De todas maneras, sin haber visto casi nada de tu problema, esto tiene
un cierto tufillo a que estas haciendo lo que no deberias en la base
de datos ( ese tipo de queries con tablas temporales surgen mucho
cuando se prototipan cosas que deberian hacerse de ota forma mediante
SQL. En el prototipo no importa demasiado el que la solucion SQL sea
un "resource hog" porque es una prueba, pero luego no escala en
produccion. Revisa bien tu solucion.

Ya te han sugerido ademas por otro lado que pruebes a quitarte t1/t2
si no las necesitas. Eso suele ser facil, solo necesitas pasar Create
table t1 as q1, create table t2 as q2, create table t3 as join(t1, t2)
from t1, t2 por un create table t3 as join(...) from (q1) t1, (q2) t2
( o, si el query se beneficia de CTEs usalas, como siempre, mide dos
veces corta una ).

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

Re: [pgsql-es-ayuda] funcionamiento de temp_buffer

[Francisco Olarte]

Buenos dias..

2016-07-10 17:41 GMT+02:00 jvenegasperu . <jvenegasp...@gmail.com>:
...
> ¿La sesion de base de datos se considera al total del codigo dentro de la
> función? es decir si tengo 3 tablas temporales y cada una usa por ejemplo 2
> Megas y asigno un temp_buffer de 10 megas aun tendria 4 megas para usar
> dentro de la función?

La sesion es todo lo que haces desde que conectas hasta que
desconectas. Vamos, un backend.

> ¿Pienso que el temp_buffer es por cada tabla temporal creada entonces en mi
> caso tengo asignado temp_buffer a 10 megas y tengo dentro de la función 3
> tablas temporales estaria usando 30 Megas?

La documentacion parece indicar lo contrario: "Sets the maximum number
of temporary buffers used by each database sessionA **session**
will allocate temporary buffers as needed up to the limit given by
temp_buffers"

Vamos, que es la sesion, no la tabla temporal.

> ¿Que pasa si la tabla origen para formar la tabla temporal pesa mas de los
> 10 Megas asignados? entonces ya no se estaria usando el temp_buffer en la
> RAM sino un espacio en disco duro?

Probablemente. Recurda que tu disco tiene cache tambien. De todas
maneras no es bueno pensar en las tablas temporales como "tablas en
disco ram", te puedes llevar sorpresas con estas cosas.

> ¿y finalmente en el caso del join cuando espacio necesitaria el temp_buffer?
> la suma del espacio de las dos tablas o solo el espacio necesario para
> almacenar temporalmente el resultado de las dos tablas?

Depende. Que hay en t1 y t2? Es id unico? existen todos los pares? Ten
en cuenta que con un t1,t2 de 100 registros cada una tu ejemplo puede
producir de 0 a 1 registros en t3 con lo que has mostrado. De
todas maneras necesitaras espacio para materializar el join del create
table, ya que el server no sabe que vas a hacer con el resultado (
igual te lias a hacer updates random en el, y necesitas todas las
filas ).

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

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

[Francisco Olarte]

Eduardo:

2016-07-07 19:40 GMT+02:00 Eduardo Morras <emorr...@yahoo.es>:
...
>> Mmm, me poner los pelos como escarpias. Yo que tu mediria primero, si
>> el esclavo es rapido Y  lleva la carga principal no creo que vayas a
>> ganar demasiado ( y to personalmente no lo haria sin una ganacia bien
>> grande ).
> Es mas que nada para evitar gastar mucho dinero en el servidor Maestro
> e invertirlo en el Esclavo, que es el que se va a llevar el trabajo
> duro. Los recursos monetarios son limitados.

Dado que la RAM es mas cara que el disco De todas formas mide en
algun desktop a ver cuanta diferencia te hace meter los logs en RAM,
ten en cuenta que al disminuirte la RAM disponible por el disco RAM
tendras que ponerle mas y pagarla. Los xlog tampoco van tan lentos,
salvo que le zurres muchisimo. Por otro lado ten en cuenta que el
esclavo tiene que guardarlos en almacenamiento estable y aplicarlos de
todos modos.


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

>> Yo, antes que esto, mediria bien a ver que pasa, y si realmente no da
>> la velocidad probaria antes de hacer esto con un fsync=off en el
>> maestro ( que hace que solo se te pudra cuando se ahostia la maquina,
>> no cuando se la pega el server, y en las pruebas que he hecho yo
>> habitualmente va a todo trapo ( lo uso mucho para actualizaciones,
>> backup, fsync off, transformaciones, fsync on ).
> Si, esta parte Alvaro tambien la ha comentado. Lo suelo usar en sqlite,
> pero no habia pensado en usarlo con Postgres.

Yo he bajado pg_restores de horas a minutos tuneando configuraciones,
y el sync es una de ellas.

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

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

[Francisco Olarte]

Hola Eduardo:

2016-07-07 17:02 GMT+02:00 Eduardo Morras <emorr...@yahoo.es>:
> Muy buenas, estoy haciendo unas pruebas en desarrollo con 2 postgres, 
> Maestro-Esclavo. La carga de trabajo va a ser principalmente de lectura. Para 
> ello voy a poner el Maestro en un servidor pequeño y el esclavo en el grande, 
> usando pgpool para hacer las consultas de lectura en el Esclavo.
> Quiero probar si crear un disco en memoria en el Maestro para contener el 
> directorio xlog (los wal) aumentara y en que medida la performance del 
> Maestro. Puedo dedicar un enlace de red para la transferencia de los wal al 
> esclavo, por lo que habria un delay minimo entre Maestro y Esclavo.

Mmm, me poner los pelos como escarpias. Yo que tu mediria primero, si
el esclavo es rapido Y  lleva la carga principal no creo que vayas a
ganar demasiado ( y to personalmente no lo haria sin una ganacia bien
grande ).

> La consulta es si una caida del Maestro y no mandar todos los wal al Esclavo 
> pueden provocar una corrupcion en este ultimo. Entiendo que no, el Esclavo 
> quedaria a la espera de los wals faltantes, no recibiria el heartbeet del 
> Maestro y haria un roolback de las transacciones a medio hacer

Hombre, normalmente una caida del maestro se recupera al levantarlo,
lo que no es asi en tu caso. El maestro se pudre y ante cualquier
caida tendrias que promover el esclavo a maestro, que tendra el
retardo que le toque, y reconstruir tu sistema desde ahi ( recopiar el
maestro, volverlos a girar ).

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.

> Ya se que el Maestro quedaria corrompido, eso no importa, puedo usar el 
> Esclavo de lectura para realizar una recuperacion o incluso otro servidor 
> (pequeño tambien) para almacenar los wals, backups u otro esclavo en sr.

Yo, antes que esto, mediria bien a ver que pasa, y si realmente no da
la velocidad probaria antes de hacer esto con un fsync=off en el
maestro ( que hace que solo se te pudra cuando se ahostia la maquina,
no cuando se la pega el server, y en las pruebas que he hecho yo
habitualmente va a todo trapo ( lo uso mucho para actualizaciones,
backup, fsync off, transformaciones, fsync on ).

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

Re: [pgsql-es-ayuda] Pregunta sobre indices

[Francisco Olarte]

Hola Alberto:

2016-06-23 6:47 GMT+02:00 Alberto Cuevas <betocuevas@gmail.com>:
> Por lo que he leído los Indices me sirven para que la búsqueda sea mas
> rápida.

Basicamente, y en ocasiones se usan para implementar unicidad.


> Tengo una tabla (por dar un ejemplo) que tiene un PK y 2 FK
> CREATE TABLE cliente (
>   id_cliente INTEGER NOT NULL (PK)
>   id_sucursal INTEGER NOT NULL (FK)
>   id_documento INTEGER NOT NULL (FK)
>
> Mi pregunta es cuando se crea en una tabla los campos Primary Key y Foreign
> Key estos por defecto ya son Indices? o debo de crearlos independientemente?

Eso de (pk) no es sql  ( otra cosa seria '-- (pk)' ), con lo que
sospecho que no es la sentencia original. En general cualquier duda
que tengas sera mejor resuelta si pones el codigo real que usas, con
algun trozo anonimizado si es secreto .


Normalmente lo que sueles hacer es "id_cliente INTEGER PRIMARY KEY".
Primary key se traduce, entre otras cosas, por "unique not null", y
unique hace que se te cree un indice, para que el servidor pueda
detectar duplicados sin leer toda la tabla. Ademas al hacer primary
key el servidor ya sabe a donde apuntan los foreign keys que declares
en otras tablas sin mas que dar el nombre de tabla referenciada. Y si
usas foreign key en las relaciones de ese tipo la gente que lea tu sql
sabra lo que quieres hacer.

> De ser la respuesta no entonces debo crear 2 indices para id_sucursal  y
> id_documento?

Las foreign key no te las indexa por defecto. La razon es que no le
hace falta, y puede que tu solo las uses en la direccion fk->pk, con
lo que indexarlas seria una perdida de tiempo. Si las usas en la
direccion inversa, lo que es muy habitual, conviene que las indexes a
mano tras crear la tabla ( direccion inversa, pk->fk es p.e. cuando
haces cosas como 'on delete cascade/set null' o 'select c.* from
cliente c, sucursal s where s.id_sucursal = c.id_sucursal and
s..).

En general depende de tus 'use pattern'. Para tus nombres de tabla
tiene toda la pinta de que deberias indexarlas, pero puee que los
llames asi y tengan datos de protones, neutrones y electrones.

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

Re: [MASSMAIL][pgsql-es-ayuda] INSTALACION DE POSTGRES

[Francisco Olarte]

Buenas tardes:

2016-06-08 18:47 GMT+02:00 Maria Antonieta Ramirez <marami...@ulsaneza.edu.mx>:
> pues la version que quiero instalar es la 9.4.0.1 porque en esa tengo mi
> base y tengo el ejecutable.

Esta es una de las razones por las que no se suele hacer
"top-posting", es dificil saber de que hablas ( y yo no me voy a
molestar en cortar y pegar para intentar corregirlo )... En otro orden
de cosas:

> aunque vi que en la pagina de descargas ya no esta esa version, esta la
> 9.4.8.
> una pregunta , si yo instalo la version 9.4.8, podre subir sin ningun
> problema un respaldo de mi base que esta en la version 9.4.0.1??

En postgres las diferencias en el tercer digito ( 9.4.x ) son
compatibles a nivel binario ( salvo rarisimas excepciones ). Es decir,
si tienes una 9.4.x e instalas una 9.4.y con y>=x puedes utilizar
directamente los mismos archivos de la BD, no hace falta ni tocarlos (
en algunas ocasiones, que suelen estar comanetadas, creo que hizo
falta un reindex, pero nada mas alla ).

Dicho esto, lo normal es avanzar siempre que puedas a la ultima
version de la linea, es decir, ve a la 9.4.8.

Respecto al respaldo, depende de como lo hayas hecho. Si lo has hecho
con pg_dump suele ser compatible con versiones del servidor iguales (
en los dos primeros digitos ) a la version de pg_dump con la que
hiciste el backup ( de pg_dump, esto es importante, la forma canonica
de pasar, p.e., de la 8.4 a la 9.3 es volcar la 8.4 con el pg_dump de
la 9.3 ( que entiende los formatos antiguos ) y con el pgrestore de la
9.3 restaturarlo. Si es un pg_basebackup realmente es una copia astuta
de archivos, y es igual de compatible que el directorio original.

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

Re: [pgsql-es-ayuda] Copiar funciones entre bases de datos

[Francisco Olarte]

Hola Jorge:

2016-05-27 13:48 GMT+02:00 Jorge Tornero - Listas <jtorlis...@gmail.com>:
> ¿Existe alguna manera de copiar funciones entre bases de datos? Me refiero a
> funciones creadas por el usuario y mediante un proceso tipo pg_dump o
> similar.

Prueba lo siguiente ( para linux, a mi me ha funcionado ):

1.- pg_dump schema only:

pg_dump -Fc -U usuario -h host -s -f tst.dmp database

Fundamental aqui, el -Fc ( lo mejor siempre para hacer cualquier
pg_dump ) y -s para schema only.

2.- Busca las funciones.

pg_restore -l tst.dmp | fgrep FUNCTION > tst.funcs

3.- Restauralas, en este caso yo te recomendaria hacerlo asi para
tener un SQL que verificar:

pg_restore -L tst.dic tst.dmp > funcs.sql

El combo -l / -L es de gran utilidada. Aparte de eso a mi me ha
ayudado en repetidas ocasiones cuando un restore da problemas y
quieres tocar algo a mitad. Cierto, con un .sql lo puedes editar, pero
con un -Fc puedes hacer un -l, partirlo en dos cachos, correr uno,
pasar un script de fixups, correr el otro, de ahi que recomiende
siempre el Fc ( ademas de un -Fc se saca el .sql, pero no al reves ).

Lo del -s arriba es por velocidad, tambien te funciona con cualquier
backup completo si ya tienes uno hecho.

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

Re: [pgsql-es-ayuda] PLPGSQL o SQL

[Francisco Olarte]

2016-05-13 16:39 GMT+02:00 Herman Estaban <hermanesta...@gmail.com>:
> Buenos días, cuando debo usar LANGUAGE plpgsql o sql?

Cuando te vaya bien, depende de lo que quieras hacer.

> Hay ventajas de uno al otro?

SQL te vale para poco mas que masajear un poco los datos o hacer 4
cuentas, pero es mas sencillo. Incluso para cuando quieres filtrar sin
mas algun acceso, o forzar accesos por funciones a alguna tabla a base
de jugar con los permisos de tablas y funciones viene muy bien. Pero
no te deja mucho mas que juntar tres queries en fila.

Si tienes necesidad de hacer algo medianamente complejo, necesitaras
plpgsql, que es un lenguage mas complejo pero te deja meter logica mas
interesante.

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

Re: [pgsql-es-ayuda] sentencia cluster

[Francisco Olarte]

2016-05-05 0:49 GMT+02:00 heriberto giron <heribertogir...@gmail.com>:
> Alguna persona me puede indicar como es el uso de la sentencia cluster y si
> en verdad agiliza o mejora las respuesta de los select, si en verdad los
> realiza mas repido

Ya te han apuntado a las docs, basicamente ahi esta todo lo que tiene
para usarla. Respecto a la velocidad, es equivalente a copiar a otra
tabla ordenado por el indice ( create table as select * from order by
campos_del_indice), mas o menos, y en algunos casos te incrementa la
velocidad. Te cuento un caso mio. Yo tengo unas tablas, que
basicamente son insert-only, con un indice por timestamp, que se
insertan muy bien correladitas. Las consultas normales van muy rapido
porque suelen tener un rango de TS, con lo que el indice las dirige a
un rango de paginas pequeño en el que estan todos los registros, y no
se lee mucho de disco y ademas se suele leer en secuencia
practicamente, y tengo montones de consultas de esas. Pero, a veces,
hay que parchear con unos cuantos updates y se 'enguarra' la tabla y
va marginalmente mas lento. En esos casos un reclustering por el
indice me devuelve la velocidad inicial ( y ademas me suele liberar
espacio, ya que me deja todas las filas sin agujeritos, causados por
los vacuums tras los updates ). Para este tipo de cosas va muy bien,
pero como se suele decir, YMMV. Ademas para mi es facil ya que
tipicamente cuando hago eso paro temporalmente las inserciones,
ejecuto los scripts de update, pego el cluster al terminar y reactivo
las inserciones. Ademas, el compactar la tabla hace que todas las
inserciones vayan en filita al final, no reaprovechando los agujeros,
lo que tambien acelera muchisimo ese proceso.

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

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

[Francisco Olarte]

2016-04-19 19:55 GMT+02:00 Kernel <jucab...@gmail.com>:
> 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.

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

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

[Francisco Olarte]

2016-04-19 20:02 GMT+02:00 Gilberto Castillo <gilberto.casti...@etecsa.cu>:
>> ¿CUAL SERIA EL TIPO DE BLOQUEO MAS ADECUADO?
> Ninguno, si quieres hacer eso has las transacciones serializable y listo.

IRL eso no es tan sencillo, hacer las transacciones serializables te
garantiza que de hacerlas lo haras bien, pero tienes que estar
preparado a reintentar si hay deadlocks, y el problema con los
procesos de facturacion en ocasiones es que son transacciones
larguisimas, y si no paras de alguna forma al resto nunca consigues
terminarlas, siempre se te mete alguien por el medio que te joroba.
Depende del diseño de la BD, pero en ocasiones tienes tu deuda tecnica
y no te queda mas que bloquear la tabla entera.

Ah, como añoro la epoca de las tarjetas y cintas en las que esto nunca pasaba.

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

Re: [pgsql-es-ayuda] Insertar Foto en tabla y como visualizarla

[Francisco Olarte]

Buenos dias:

2016-04-17 6:48 GMT+02:00 José Fermín Francisco Ferreras
<josefermi...@hotmail.com>:
> Como puedo insertar una foto en una tabla en postgres mediante comando:
> CREATE TABLE esquema.documento
> (
>   numero_documento serial NOT NULL,
>   fecha_documento date NOT NULL,
>   nombre_cliente integer NOT NULL,
>   foto_documento bytea NOT NULL,
> );
> Me pregunto si se insertara de esta manera:
> insert into esquema.documento(fecha_documento, nombre_cliente,foto) values
> ('2016-04-17','Juan Perez','c:\foto.jpg');

Desde luego, asi no. Tienes que leer en el cliente la foto de alguna
manera y ponersela en alguna sintaxis que se entienda, hay varias en
el manual. El como depende sobre todo de que aplicacion estes usando
para manejarla (p.e., si estas usando psql tienes pocas alternativas
aparte de ponerla como una constante ).

P.e. Un jpg cualquiera:

$ od -t x1 -tc  redacted_filename.JPG | head
000  ff  d8  ff  e0  00  10  4a  46  49  46  00  01  01  01  02  58
377 330 377 340  \0 020   J   F   I   F  \0 001 001 001 002   X

puede describirse como una constante bytea
E'\\Xffd8ffe000104a464946000101010258...'

Dependiendo de tu entorno hay muchas formas de construirla, p.e.

$ head -c16 Documents/Boda\ y\ abuelos.JPG | perl -e "\$q=qq('); "'
undef $/; print "E$qx",unpack("H*",scalar(<>)),"$q\n"'
E'\\xffd8ffe000104a464946000101010258'

( Parece mas de lo que es por lo dificil que es meter un script de
perl que use ' y " y \ en la linea de comando del bash, probablemente
en un archivo te quede solo:

#!/usr/bin/perl
undef $/; # Slurp whole stdin in one go.
print "E'x",unpack("H*",scalar(<>)),"'\n"'

> Y como se puede visualizar el registro con su imagen??

Pues como al reves, consigues el byte a y lo pasas a binario y se lo
das a la rutina / programa.

> Alguien me puede ayudar??

Seguro, pero deberias empezar por decir mucho mas de lo que pones,
como que lenguage/sistema operativo/entorno estas usando ( parece
windows por el C:\, con lo que yo no mucho, pero hay mucho experto de
windows suelto por aqui ) ( porque p.e. lo que te dije fallara casi
seguro en windows por el tema del binmode aunque tuvieras perl y head
).

Un saludo.
   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

Re: [pgsql-es-ayuda] Nuevo campo en todas las tablas de la base de datos

[Francisco Olarte]

Buenos dias:

On Wed, Apr 13, 2016 at 12:33 AM, mauricio pullabuestan
 wrote:
> Necesito crear un campo en todas que no tengan un campo en concreto para ello 
> tengo 2 funciones, el problema se da es que la funcion
> campo_check_fnc me devuelve también las vista y se produce un error.
> Como puedo fitrar que solo me devuelva tablas.

Asi por encima tu problema parece ser que seleccionas de donde no
debes ( o para ser exacto no seleccionas de todos los sitios donde
debes ):

>  SELECT table_schema, table_name
>   FROM information_schema.columns
...
>SELECT table_schema, table_name, column_name = 'mi_campo' As 
> existe_campo
> FROM information_schema.columns
...

Si vas a las docs veras ( lo siento, en ingles, no se donde estan las
docs en español ):

http://www.postgresql.org/docs/9.5/static/infoschema-columns.html

34.16. columns

The view columns contains information about all table columns (or view
columns) in the database. System columns (oid, etc.) are not included.
Only those columns are shown that the current user has access to (by
way of being the owner or having some privilege).

Prueba a hacer un join con tables para coger solo las tablas:

http://www.postgresql.org/docs/9.5/static/infoschema-tables.html

34.52. tables

The view tables contains all tables and views defined in the current
database. Only those tables and views are shown that the current user
has access to (by way of being the owner or having some privilege).

table_type - character_data - Type of the table: BASE TABLE for a
persistent base table (the normal table type), VIEW for a view,
FOREIGN TABLE for a foreign table, or LOCAL TEMPORARY for a temporary
table

( Podrias probar a hacer un not exists o u nouter join filtrado con
views, pero creo que tables.table_type te dara mejor resultado ya que
te permite decidir que hacer con las FOREIGN TABLE y/o TEMPORARY TABLE
).


Fancisco 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

Re: [pgsql-es-ayuda] permisos del directorio postgresql

[Francisco Olarte]

2016-04-06 8:47 GMT+02:00 Horacio Miranda <hmira...@gmail.com>:
> Si es linux,  chown postgres: -Rv /var/lib/pgsql

chown = change owner, una pista te la da el que no le das permisos, le
das un usuario, los permisos unix basicos se cambian con chmod, y los
avanzados ya depende mucho del FS, y es el chacl y vecinos.
$ chown --help
...
Change the owner and/or group of each FILE to OWNER and/or GROUP.
...
$ chmod --help
...
Change the mode of each FILE to MODE.
...

Normalmente por permisos se suele entender el MODE.

Sin prejuicio de que alguien que reporta sin decir el SO puede que
haya cambiado el owner, no los permisos.

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

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

[Francisco Olarte]

2016-03-19 18:04 GMT+01:00 Edwin Quijada <listas_quij...@hotmail.com>:
> Se puede replicar una sola BD y no el cluster con logical replication?

Si, de hecho solo se puede replicar una ( puedes replicar el cluster,
pero una a una )

Eso si, mientras que todo lo que necesitas para streaming replication
viene con el servidor de postgres para hacer cosas con logical tendras
que buscar algun componente mas, como el pglogical de 2ndquadrant. Los
he mirado alguna vez pero no los he llegado a usar en prod. porque
siempre tengo que replicar los clusters enteros.

El pglogical es similar a la tipica replicacion por triggers, pero
aprovechandose de que toda la informacion necesaria esta en el WAL.
Permite, teoricamente, todo lo que esta, como replicaciones parciales,
multidireccionales, entre distintos sistemas etc..., pero la parte que
viene incluida en el servidor es solo la de leer lo que ha pasado en
el master.

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

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

[Francisco Olarte]

Alberto:

2016-03-15 16:54 GMT+01:00 alberto cordones <listas.alberto.cordo...@gmail.com>:
> Hola Jaime, asi tengo configurado la replicacion logica sin utilizar
> pglogical y funciona bien. Se que funciona bien ya que he hecho muchas
> pruebas de replicación y todas exitosas, es por eso que me di cuenta que los
> archivos wal crecen mucho al caer uno de los esclavos
> Configuracion de todos los nodos:
...
> Los nodos esclavos tiene un archivo extra llamado recovery.conf
> esclavo 1
> standby_mode = 'on'
> primary_conninfo = 'user=postgres host=192.192.192.3 port=5432
> sslmode=prefer sslcompression=1 krbsrvname=postgres'
> primary_slot_name = 'slave1'

Eso NO es replicacion logica, es steaming-replication ( fisica, por
llamarla de alguna forma ) con slots. Aunque se llamen slots lo unico
que comparten con los de logica es mantenerte vivos los segmentos de
wal, pero no slots logicos.

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

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

[Francisco Olarte]

Alberto:

2016-03-15 1:17 GMT+01:00 alberto cordones <listas.alberto.cordo...@gmail.com>:
> Muchas Gracias Jaime, por aclarar mis dudas, a tu pregunta, no, solo estoy
> usando logical replication a nivel de wal_level, no estoy utilizando
> pglogical

Bajalo entonces, salvo que lo quieras por tenerlo preparado para hacer
cosas de logical.

Segun la documentacion ( en ingles, lo siento, ni se donde esta la doc
en castellano, siempre me voy al original, de
http://www.postgresql.org/docs/9.5/static/runtime-config-wal.html#RUNTIME-CONFIG-WAL-SETTINGS
)

"wal_level determines how much information is written to the WAL. The
default value is minimal, which writes only the information needed to
recover from a crash or immediate shutdown. archive adds logging
required for WAL archiving; hot_standby further adds information
required to run read-only queries on a standby server; and, finally
logical adds information necessary to support logical decoding. Each
level includes the information logged at all lower levels. This
parameter can only be set at server start."

Como ves para streaming replication solo necesitas archive ( igual que
para log shipping, al fin y al cabo es mas menos un log shipping
rapido por red ). hot_standby te permite leer en el esclavo ( que
exige mas informacion para que no se destruya informacion que el
esclavo esta leyendo, es decir, si tu estas haciendo un select de una
tabla en el esclavo no puede aplicar logs de un delete en esta, con lo
que se debe pasar informacion de transacciones y cosas asi ) y el
logical incluira algo mas que le haga falta ( que estara en las docs
).

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

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

[Francisco Olarte]

Alberto:

2016-03-14 21:57 GMT+01:00 alberto cordones <listas.alberto.cordo...@gmail.com>:
> esto ultimo no lo entendi muy bien
> "Creo que ademas va por BD, no por cluster, lo que en algunos casos te
> puede disminuir muchisimo el trafico."
> ..ya que cuando configuro el servidor (postgresql.conf), lo configuro para
> todo el cluster, no para una sola base de datos

Veamos.

La streaming replicacion va mandando todo el wal por una conexion y
aplicandolo, con lo que manda el cluster entero, si hay 10 bd las
manda todas. Si creas una nueva se manda sola, incluyendo su creacion.

Hay unos slots de replicacion par streaming, que lo que hacen es que
el maestro sepa cuanto wal les falta a los esclavos, y que se pueden
usar para que no borre los wal durante un base backup ( que es
parecido a una replicacion en streaming ) o que espere a los esclavos.
Basicamente se crea uno por cliente persistente que tienes y contienen
poco mas que cual es el ultimo log procesado en el esclavo para que el
master pueda calcular el minimo de eso y saber que hasta ahi puede
borrar.

Luego estan los slots logicos, que son distintos. Se crean POR BD, con
funciones SQL contra esa BD, y sirven para dos cosas. Por un lado
tienen un puntero para que no se borren los wal, como los otros, pero
por otro lado entre su funcionalidad basica y sus plugins lo que hacen
es extraer los cambios de la BD en la que estan para presentarlos en
una forma estandard. Eso hace que valgan para mas cosas pero son mas
complicados de manejar.

Cuando usas la replicacion logica lo que recibes no es el wal crudo,
que es algo como 'escribir estos trozos de bytes en estas paginas de
este archivo' ( lo que es muy rapido, pero poco fino, y solo vale
entre dos servidores de postgres muy similares ), sino cosas como
"poner tal cosa en tabla tal, borrar tal otra,", y ademas solo de una
BD. Ese flujo de informacion es mas compacto, lo que puede disminuir
tu trafico de red aun cuando repliques todo ( de la misma forma que,
p.e., un pg_dump suele ocupar, aun sin compresion, menos que la BD en
disco ).

De hecho hay una cierta similitud, la streaming replication se parece
a copiar el directorio de datos del server. Va todo el cluster pero es
simple y rapido. La logica es parecida a un pg_dump/pg_restore, va una
base de datos, es mas flexible, se mueven menos datos ( por ejemplo no
van los indices ), pero es mas compleja y exige mas procesos. Ademas
el dump-restore funciona entre versiones, y te vale hasta para meter
datos en otro motor de bd con un poco de cuidado, como puedes hacer
con la replicacion logica.

Vamos, que son animales distintos.

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

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

[Francisco Olarte]

Buenas:

2016-03-14 20:43 GMT+01:00 alberto cordones <listas.alberto.cordo...@gmail.com>:
> Si, muchas gracias a todos.ya que se me aclararon algunas dudas, sin embargo
> por lo que he estado leyendo, logical replication es es mejor que
> hot_standby,independiente del tema de la cantidad de wal que se generan. o
> estoy equivocado

Depende de para que. Si quieres replicar el cluster entero el
streaming replication ( hot standby ) total tiene la ventaja de que es
muy simple. El logical es, por lo que se, mas flexible, pero me temo
que dependera de que quieres exactamente conseguir. Si tienes lo que
yo, dos maquinas una en servicio otra esperando, con un enlace de red
dedicado de una a otra ( con lo que el ancho de banda es salvaje y el
retardo minimo, y como la secundaria solo aplica los pone nada mas
llegan ) el streaming va genial, y ademas no tengo que hacer nada
cuando creo nuevas BD. Ademas creo que hay cosas como el synchronous
que no se pueden hacer con el logical replication ( que es similar a
una replicacion por triggers superoptimizada ).

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

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

[Francisco Olarte]

2016-03-14 19:27 GMT+01:00 Hellmuth Vargas <hiv...@gmail.com>:
> 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.

Creo que ademas va por BD, no por cluster, lo que en algunos casos te
puede disminuir muchisimo el trafico.

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

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

[Francisco Olarte]

Hola Alberto:

2016-03-14 19:08 GMT+01:00 alberto cordones <listas.alberto.cordo...@gmail.com>:
> 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.

Precisamente de eso se trata, cuando el master deje de responder te
daras cuenta. Los slots tan para que cuando quieras garantizar que el
maestro no borra logs no transmitidos, incluso si no recuerdo mal las
ultimas versiones de streaming replication permiten usarlos para eso.
Por otro lado la unica forma de garantizar que el esclavo no pierde
logs cuando esta caido es que el maestro los retenga todos, con lo que
no podra avanzar si se queda sin disco, has de elegir una de dos, o
permites parar el maestro o permites perder el esclavo.

Por otro lado los replication slots pueden borrarse desde otra
aplicacion, con lo que podrias probar a monitorizar el espacio en
disco del maestro y borrarlos ( emitiendo la correspondiente alerta )
cuando este a punto de quedarse sin espacio. La ventaja de esto frente
a un wal-keep-segments enorme es que en el primer caso necesitas
espacio para el monton de WALs siempre, haciendo algo asi eres mas
dinamico, si el maestro tiene mucho espacio libre donde guarda el WAL
aguanta retrasos enormes, pero si tiene poco no se para, aunque
pierdes mas esclavos. Te puede ir bien porque en el caso de que un
esclavo se pare mucho y te machaques su slot probablemente es que esta
tan mal que es mejor hacer una reconstruccion con pg_basebackup ( que,
si no recuerdo mal, tambien puede usar replication slots ).

Nunca vas a encontrar un sistema que permita recuperarse de un retardo
ilimitado en el esclavo sin un almacenamiento ilimitado en el maestro,
o en algun otro sitio, si haces wal shipping.

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

[pgsql-es-ayuda] Re: [pgsql-es-ayuda] Tamaño de base de datos

[Francisco Olarte]

Buenas tardes:

2016-03-12 15:00 GMT+01:00 Edwin De La Cruz :
> Estimados. Saludos cordiales.
> Tengo una consulta un poco básica, en mi servidor tengo una base de datos
> con más o menos unos 500 millones de registros con tablas particionadas por
> meses y va llegando el tamaño a los 70 gigas.

Dado que parece que sabes como sacarlo, iria bien que indicases
cuantos registros por particion tipica, y el tamaño de una con sus
indices, siempre es mas facil..

> Pero cuando saco respaldo no supera los 5 gigas.

... asi como que comando usas para el respaldo ( e iria bien si
pudieras hacerlo de una sola particion, la que selecciones como
tipica, y mirases el tamaño de solo esa ). Es normal que las tablas
ocupen menos al volcarlas ( ya que aunque algunos campos perversos
crecen al pasarlos a textos muchos disminuyen, porque la
representacion en disco esta pensada para ser actualizable y muybien
delimitada, no super compacta ) y que suelen comprimirse en stream (
todo el volcado de golpe, lo que hace que algunos se compriman
fantasticamente ).

> Como puede ser eso, seguro hay algún tipo de compresión
> pero como puedo hacer para que mi tamaño de base de datos se comprima?
> Los campos de datos tipo text son pocos y la mayoría no superan los 300
> caracteres, exepto un campo que es tipo text con textos que pueden ser
> grandes, más de 1000 caracteres, hay alguna forma de comprimir sólo ese
> campo o el texto antes de insertarl0?

Puedes hacer cosas con la tabla, pero sin saber la estructura total
puede ser peor el remedio. Supongo que no tendras campos tipo CHAR(n)
en lugar de VARCHAR(n) ( eso te mata, mira
http://www.postgresql.org/docs/9.5/static/datatype-character.html ,
"The storage requirement for a short string (up to 126 bytes) is 1
byte plus the actual string, which includes the space padding in the
case of character" ). Por otro lado supongo que no tendras problemas
de tabla con mucho traqueteo y filas muertas ( eso lo sabras por tu
patron de uso, y si la carga te lo permite puedes hacer un vacuum full
en una particion antigua, o copiar la tabla a una nueva sin indices
para verificarlo ).



> Posibkemente me digan que quizá los índices son muy grandes, pero no, el más
> grande no supera un giga.

 ¿ Pero cuantos indices tienes por particion ? ( de ahi la pregunta de arriba ).

> Son algunas preguntas y espero que me puedan orientar al respecto.

Ahi te van algunas mas, y alguna indicacion que puede ayudarte.

Franciso 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

Re: [pgsql-es-ayuda] Ayuda a conexion

[Francisco Olarte]

Buenas Tardes:

2016-01-14 17:32 GMT+01:00 Luis Alberto Suarez <luissuarez2...@gmail.com>:
> Tenemos una aplicacion publicada para que la podamos acceder externamente a
> través de internet, esta aplicación tiene su motor de base datos postgresql
> 8.4, pero al conectarnos a la aplicacion nos permite un conexion normal pero
> cuando vamos a accer a una base datos nos arroja el siguiente mensaje "Se
> produjo un error al realizar la operacion, por favor comunicarse con el
> administrador.


Sin mas detalles, dificil sera que te ayudemos, dado que no sabemos
que es "la aplicacion publicada" y que el error no te lo da al
conectar a postgres sino "al conectarnos a la aplicacion".

> Ya revise los archivos de configuracion, el postgresql.conf y el pg_hba.conf
> veo que estan bien

Pues si estan bien, el problema parece ser en la aplicacion.

> Que puede estar sucediendo que tips me pueden dar para darle solución a este
> inconveniente

Dar algun detalle mas, esto es como si te digo "compre sal, revise que
es NaCl, pero la comida no me sabe bien", estamos un poco lejos del
problema.

En otro orden de cosas, si necesitas la 8.4, vale, pero es un pelin
vieja y totalmente fuera de soporte.

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

Re: [pgsql-es-ayuda] Consultas complicada

[Francisco Olarte]

Buenos dias:

Una respuesta, larga, te voy desarrollando cosas.


On Fri, Dec 18, 2015 at 8:44 PM, ViBaSoft <vibas...@gmail.com> wrote:
> Quiero sacar  el precio minimo, máximo, media por mes por columna y una
> general, en la general me sale bien pero por mes columna no me trae el
> minimo. Me trae 0(cero) siempre en la columna min_enero

Tu problema es el clasico de mal valor por defecto. Estas haciendo el
MIN de una columna de precios ( >=0 ) con un 0 cuando no es enero, con
lo que te sale 0:

> MIN(CASE WHEN extract(month from c.fecha_factura)=1 THEN cd.preciocompra
> ELSE 0 END) AS precio_min_enero,

En cuanto una fila de febrero entra el el case da 0, el minimo es 0.

Prueba a poner un numero enorme en el else, no se cual decirte ya que
no has puesto el esquema de la tabla pero siendo precios si pones
'ELSE 99' te deberia valer.

Esa es la solucion clasica usada cuando calculas un minimo corrido en
un lenguaje clasico, inicializar el minimo al nuero mas largo que
puedas y si el valor leido es menor, actualizr ( min=, if
curr select min(case when mes=1 then precio else 0 end) from (
values(1,2.0),(1,3.0),(2,1.0),(2,4.0)) as datos(mes,precio); min
-
   0
(1 row)

La solucion con el 9:

cdrs=> select min(case when mes=1 then precio else 9 end) from
( values(1,2.0),(1,3.0),(2,1.0),(2,4.0)) as datos(mes,precio);
 min
-
 2.0
(1 row)

Que tiene un problema si no hubiera datos de enero, por ejemplo para
el mes 3 pasa esto:

cdrs=> select min(case when mes=3 then precio else 9 end) from
( values(1,2.0),(1,3.0),(2,1.0),(2,4.0)) as datos(mes,precio);
min
---
 9
(1 row)

Que es necesario controlar fuera de banda, si en lugar de 999
usas null te viene un null de resultado:

cdrs=> select min(case when mes=3 then precio else null end) from (
values(1,2.0),(1,3.0),(2,1.0),(2,4.0)) as datos(mes,precio);
 min
-

(1 row)

Que es mas facil de distinguir. Comprobamos que el caso del 1 sigue
funcioanado igual:

cdrs=> select min(case when mes=1 then precio else null end) from (
values(1,2.0),(1,3.0),(2,1.0),(2,4.0)) as datos(mes,precio);
 min
-
 2.0
(1 row)

Y ademas el null vale tambien para max:

cdrs=> select max(case when mes=1 then precio else null end) from (
values(1,2.0),(1,3.0),(2,1.0),(2,4.0)) as datos(mes,precio);
 max
-
 3.0
(1 row)

E incluso para avg, sum y count:

cdrs=> select avg(case when mes=1 then precio else null end) from (
values(1,2.0),(1,3.0),(2,1.0),(2,4.0)) as datos(mes,precio);
avg

 2.5000
(1 row)
cdrs=> select count(case when mes=1 then precio else null end) from (
values(1,2.0),(1,3.0),(2,1.0),(2,4.0)) as datos(mes,precio);
 count
---
 2
(1 row)
cdrs=> select sum(case when mes=1 then precio else null end) from (
values(1,2.0),(1,3.0),(2,1.0),(2,4.0)) as datos(mes,precio);
 sum
-
 5.0
(1 row)


Lo que te simplificaria bastante tu query, y lo deja, IMHO, mas claro,
ya que en SQL el NULL se ve enseguida como 'falta dato' o 'dato
desconocido' o 'no procede'. Incluso, aprovechando que el null
propaga, puedes hacerlo en dos partes, primero sacas una columna con
los datos de enero luego agregas. Como usas una version EOL no voy ni
a intentar hacerte una prueba real que no se si funcionara, no voy a
ir buscando documentaciones historicas, pero seria algo asi.

Tabla extendida:

SELECT
 cd.codigo as codigo,
 cd.cantidad as cant,
 preciocompra,
 (CASE WHEN extract(month from c.fecha_factura)=1 THEN cd.cantidad
ELSE NULL END) AS cant_enero,
 (CASE WHEN extract(month from c.fecha_factura)=1 THEN
cd.preciocompra ELSE NULL END) AS precio_enero
FROM compras cd inner join compra c on cd.idcompras=c.idcompras
WHERE trim(cd.codigo)='90-131-00-1' and c.fecha_factura>='2015-01-01'

Y luego puedes agregar con eso:

select
codigo,
sum(cant) as cant,
min(preciocompra) as min_precio,
max(preciocompra) as max_precio,
sum(cant_enero) as cant_enero,
min(precio_enero) as min_precio_enero,
max(precio_enero) as max_precio_enero,
sum(precio_enero*cant_enero)/sum(precio_enero) as media_enero
FROM (** LO DE ARRIBA**) as extendida
GROUP BY codigo.

**
> Trabajo con porstgres 9.0

Esa version esta EOL, yo que tu iria mirando de actualizar. De hecho
el query de ejemplo te lo hubiera puesto con WITH pero ni recuerdo si
lo soportaba en esa version.

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

Re: [pgsql-es-ayuda] error en insert de \\\ con postgres 9.4

[Francisco Olarte]

Buenas tardes.

2015-11-26 19:59 GMT+01:00 heriberto giron <heribertogir...@gmail.com>:
> al parecer el campo que posee los datos separados por  \\\ lo convierte a
> \134

Sin ver mas datos, como como sacas el dato, que query mandas, que
definicion de columna tienes, dificil es que te puedan ayudar.

De todas maneras si en 9.0 te funcionaba y en 9.4 no, dado que en una
cadena con escapes octales \134 es una \, y dado que entre esas dos
versiones cambiaron el standard_conforming_strings yo me miraria la
documentacion de ese parametro porque hay una forma de ponerlo para
que los servidores de la 9.4 se comporten como los de la 9.0 ( lo que
cambio fue el valor por defecto del parametro, no recuerdo todos los
detalles pero estan en el manual ) y puede que eso resuelva tu
problema inmediato.

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

Re: [pgsql-es-ayuda] libreria de funciones?

[Francisco Olarte]

Kernel:

2015-11-16 12:25 GMT+01:00 Kernel <jucab...@gmail.com>:
> Se puede ver en alguna tabla el codigo de las funciones?

Dejando aparte el link que te han dado en stack overflow y el clasico
'RTFM' (http://www.postgresql.org/docs/9.4/static/catalog-pg-proc.html,
pg_proc.prosrc y amiguetes ), para estos casos suele venir muy bien
usar el psql con un '\set ECHO_HIDDEN on'. Con eso, si eres capaz de
sacar el fuente de una funcion ( \df+ si no recuerdo mal ) o editarla
( \ef, IIRC ) puedes ver como lo hace y partir de ahi.

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

Re: [pgsql-es-ayuda] problema con codificacion

[Francisco Olarte]

2015-11-13 21:53 GMT+01:00 Esneiker Enriquez Cabrera <eenriq...@cav.desoft.cu>:
> Escribo porque estoy probando guardar información encriptada en la base de
> datos con codificación utf8 y todo resulta bien, excepto cuando la
> información tiene caracteres especiales, se guarda basura.
> A continuación les pongo un ejemplo.
> select
> encode(decrypt(encrypt('telefónico','password','3des'),'password','3des'::text),
> 'escape'::text);
> el resultado que me retorna es “telef\303\263nico”, en lugar de telefónico.
> Espero que me puedan indicar cómo hacer el tratamiento correcto.

Esto huele a lo de siempre, UTF-8 es una forma de codificar texto en
bytes, la criptografia va en bytes, tenemos el encoding de la base de
datos por un lado, nos hemos liado.etc etc...

No te lo puedo asegurar, pero el hecho de que necesites encode ya te
da una pista. Encrypt toma bytea como datos, PEEERO, tu le has dado un
texto fiandote de la conversion por defecto, decrypt devuelve bytea.
Luego coges y le dices que te lo imprima en escape, y lo hace bien, de
hecho :

cdrs=> show client_encoding;
client_encoding
-
 UTF8
(1 row)

cdrs=> select encode('telefónico', 'escape');
  encode
---
 telef\303\263nico
(1 row)

El problema es que el decrypt/encrypt es el equivalente a pasat
telefónico a bytea:


cdrs=> select 'telefónico'::bytea;
  bytea
--
 \x74656c6566c3b36e69636f
(1 row)

cdrs=> select encode('telefónico'::bytea, 'escape');
  encode
---
 telef\303\263nico
(1 row)

Y lo que tu quieres es que te interprete esos bytes como utf8, no que
te los imprima escapados, para eso necesitarias una funcion de
conversion de bytes a string, como por ejemplo:

cdrs=> select convert_from('telefónico'::bytea, 'UTF-8');
 convert_from
--
 telefónico
(1 row)

No te lo puedo probar porque no tengo instaladas las crypto, pero
juraria que es eso.

Por cierto, si lo es tu codigo tiene un problema, que dejas la
conversion de texto a bytea a merced del encoding de la conexion y
otroas cosas, lo que no es recomendable, particularmente en
criptografia. Probablement tus problemas vienen de que la conversion
no es reversible:


cdrs=> select 'telefónico'::bytea::text;
   text
--
 \x74656c6566c3b36e69636f
(1 row)

Las cosas te iran mejor/mas simples, si al igual que apareas
encrypt/decrypt haces lo mismo con convert_from, convert_to, asi te
aseguras de que lo hace en el encoding que tu le dices
independientemente de la conexion:

cdrs=> select convert_from(convert_to('telefónico','UTF-8'), 'UTF-8');
 convert_from
--
 telefónico
(1 row)

Que funciona con otros encoding ( que soporten los caracteres que usas ):

cdrs=> select convert_from(convert_to('telefónico','LATIN-1'), 'LATIN-1');
 convert_from
--
 telefónico
(1 row)

A pesar de que:



cdrs=> values(convert_to('telefónico','LATIN-1'), 'LATIN-1') union
values(convert_to('telefónico','UTF-8'), 'UTF-8');
 column1  | column2
--+-
 \x74656c6566c3b36e69636f | UTF-8
 \x74656c6566f36e69636f   | LATIN-1
(2 rows)

Si haces esto se ve la simetria,
select(convert_from(decrypt(encrypt(convert_to.. no te fies nunca
de las conversiones por defecto cuando estas usando bytea, siempre se
revuelven y te muerden donde menos lo esperas.



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

Re: [pgsql-es-ayuda] Desactivar y activar un trigger o constraint desde sentencia SQL

[Francisco Olarte]

2015-10-26 9:44 GMT+01:00 Carlos Joaniquet <cjtam...@yahoo.es>:
> Perfecto y nunca pensé que sería un ALTER TABLE.

Si te miras la pagina del alter trigger ( sitio tipico para buscarlo
), te lo dice, asi como la razon:

Notes

The ability to temporarily enable or disable a trigger is provided by
ALTER TABLE, not by ALTER TRIGGER, because ALTER TRIGGER has no
convenient way to express the option of enabling or disabling all of a
table's triggers at once.

( por si alguien no lee ingles 'La capacidad de habilitar o
deshabilitar temporalmente un trigger esta en alter table, no el alter
trigger, porque no hay una forma conveniente de expresar la opcion de
habilitar o deshabilitar todos los triggers de una tabla a la vez con
alter trigger ( ya que esta sentencia va condicionada al nombre del
trigger, añado ) )


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

Re: [pgsql-es-ayuda] Desactivar y activar un trigger o constraint desde sentencia SQL

[Francisco Olarte]

2015-10-25 2:07 GMT+01:00 Carlos Joaniquet <cjtam...@yahoo.es>:
> A programa cliente me refiero a un programa de gestión que se conecta a la db 
> para obtener y volcar información y desde donde quiero hacer alguna tarea en 
> la que en un momento determinado necesito desactivar por ejp un trigger. El 
> programa para actualizar info hace UPDATE o DELETE y para obtenerla SELECT. 
> ¿Qué intrucción se manda para activar-desactivar un trigger o una 
> restricción? Ahora lo hago con pgAdmin manualmente.

Veamos. Conozco el pgAdmin, aunque no lo uso nunca porque dificulta
mucho la administracion ( por lo menos en mi forma de trabajar, yo soy
verbal y ademas tiro del manual de postgres que tiene casi todos los
ejemplos para psq ). La diferencia con un programa como el psql,  es
de interfaz de usuario mayormente, la del psql es poco mas que mandar
al servidor lo que tecleas mientras que la del pgadmin es mucho mas
compleja, con menus y tal, pero puede ir mejor en segun que casos. No
tengo ni idea de como desactiva los triggers, supongo que con algun
menu o algo asi en la visualizacion, pero el SQL para hacerlo viene en
el manual ( Y ya te han mandado un link por ahi ), y al final tiene
que hacerlo mandado sql al servidor. Casi seguro que tiene alguna
opcion para ver los comandos que le manda al servidor. Si te
encuentras comodo con el yo te recomendaria que la buscases y mirases
que comando usa cuando los deshabilitas usandolo, y no tienes mas que
repetirlo. Normalmente suelen ser cosas tipo alter table, que a
efectos de mandarlo desde otra aplicacion es lo mismo que mandar un
update ( de hecho probablemente podras mandarlo desde el pgadmin en la
ventana que tenga de sql ).

> Me espero a actualizar. Por ahora va todo perfecto.

Mu bien, aunque igual esperas un rato. No se tu pero yo en general no
suelo poner las *.*.0, me espero a la primera revision, aunque si no
sale en unos meses la pongo.

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

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

[Francisco Olarte]

2015-10-25 0:29 GMT+02:00 Horacio Miranda <hmira...@gmail.com>:
> https://wiki.postgresql.org/wiki/SoundexESP

Eso si que te puede valer, pero eso NO es el soundex, ya podrias haber
puesto el link al principio y nos hubieramos ahorrado unas
explicaciones. ( de hecho esta bastante currada, ya que parece que
quiere ir a palabras en general ). Tiene un par de problemas para lo
que parece querer, eliminar tildes, originados por ser una imitacion
del soundex ( y que comparte con este ), que ignora las vocales y que
ignora todo lo que vaya detras de la cuarta silaba, pero segun lo que
quieras puede ser hasta mejor, como lo del FTS que se sugirio. Un poco
larga, pero si se mete un indice funcional le da igual.


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

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

[Francisco Olarte]

2015-10-24 14:07 GMT+02:00 Hellmuth Vargas <hiv...@gmail.com>:
> Y porque no considerar FTS?

Normalmente es una buena solución, si no te importan los falsos
positivos ( porque me temo que te pueda devolver cosas como metodos,
metodico y/o metodologia, ahora no tengo forma de probarlo ) y que el
indice te salga algo mayor ( si no recuerdo al lo eran, pero no creo
que importe si usas la flexibilidad que te da ). No conociendo bien el
problema, yo creo que es lo mejor, y con lo que se dijo yo optaria
probablemente por FTS+app filtering si hay algun falso positivo. (
habiendolo sugerido tu con anterioridad yo me limite a indicar como se
hace para indexar sin acentos por si no queria FTS )

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

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

[Francisco Olarte]

Un poco fuera de topico. No se como se traduce 'top posting' al
castellano, y soy un poco nuevo en esta lista, pero es ¿costumbre por
aqui ?

2015-10-24 14:01 GMT+02:00 Horacio Miranda <hmira...@gmail.com>:
> Soundex es para eso, si lo quieres usar bien, de lo contrario debes hacer un
> indice con todas las variantes que se te puedan imaginar.

Soundex, si no recuerdo mal ( y si knuth ya la wikipedia se equivocan,
ya que PSLM lo mire antes de contestarte la primera vez ), se invento
para los nombres de la gente en ingles, no para textos genericos en
cualquier idioma ( por eso descarta las vocales asi como "yhw" que no
suelen dar mucha informacion ). El primer problema, tildes aparte, es
que te va a dar lo mismo para metodo, metida, matado, medida, ... Lo
he usado, y nisiquiera funciona bien para los nombres en castellano (
donde en general no suele ser necesario, dado que la pronunciacion es
muy directa, normalmente con omitir tildes vas sobrao ).

No tienes que hacer un indice con todas las variantes si quieres solo
quitar tildes. Tienes que hacer un indice funcional y consultar por la
funcion. Igual que para hacer una consulta que no distinga mayusculas
de minusculas no hay que indexar or todas las variaciones, vale por
indexar por la palabra en mayusculas y preguntar por la palabra en
mayusculas.

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

Re: [pgsql-es-ayuda] duda sobre indices

[Francisco Olarte]

Buenos dias:

2015-10-22 22:44 GMT+02:00 Igniris Valdivia <ivaldi...@xetid.cu>:
> tengo un indice btree que contiene dos campos digamos id1 e id2 pues se debe
> garantizar la unicidad de la combinacion de estos campos
> ahora en la consulta donde la uso se usan los operadores igual e IN como por
> ejemplo:
>
> id1=id3 AND id2 IN (1,2,3)
>
> y como el indice es compuesto la busqueda del IN la hace secuencial
> que pudiera hacer para arreglar eso sin tener que crear un nuevo indice solo
> para el capo id2 pues considero que esto ralentizaria aun mas la consulta en
> lugar de optimizarla

Como ya te han dicho, un explain analyze ayudaria. Añadire que ademas
la definicion real de las tablas/indices es necesaria, el optimizador
es un bicho complicado y diferencias pequeñas en las definciones
pueden dar grandes diferencias en los resultados.

¿ Cuando dices que la busqueda la hace secuencial a que te refieres
exactamente ? ¿ Secuencial en el resultado de buscar id1, en toda la
tabla ?

Dicho esto, en general un indice por (id1, id2) te vale para buscar
por id1 o por ambos, pero no por id2. En tu caso puede que el
opitmizador no llegue a entender todo el query, y a veces puedes
mejorarlo pidiendo (id1=id2) and (id2=1 or id2=2 or id2=3), todo es
cuestion de probar.

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

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

[Francisco Olarte]

2015-10-22 22:37 GMT+02:00 Horacio Miranda <hmira...@gmail.com>:
> Por que no usar soundex ?
> http://www.postgresql.org/docs/9.1/static/fuzzystrmatch.html

¿ Porque, segun el primer parrafo de la pagina a la que apuntas "The
Soundex system is a method of matching similar-sounding names by
converting them to the same code. It was initially used by the United
States Census in 1880, 1900, and 1910.>>>> Note that Soundex is not
very useful for non-English names.<<<<<" y el uso de tildes implica
non-English names ?

AFAIK el soundex NO esta definido si hay tildes y tira todas las
vocales no iniciales. Yo en esos casos siempre he optado por hacer un
folding si se conoce el alfabeto de entrada, algo como [select
translate('Método', 'áéíóúñ','aeioun');]. Si se encapsula eso en una
funcion SQL marcada como "strict inmutable" se puede hacer un indice
por esa expresion y usarla en los queries ( si se hace cuidado, no se
puede cambiar la funcion despues de crear el indice, por algo se marca
immutable, hay que reindexar ). Yo he usado eso para cambiar las cosas
mas habituales del latin1 a ascii ( la db era utf8, pero como los
usuarios venian de windows, uno de los pocos SO que es unicode por
dentro, los datos usaban solo, como es habitual, caracteres presentes
en win1252), ya que tenia un problema similar.

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

Re: [pgsql-es-ayuda] Desactivar y activar un trigger o constraint desde sentencia SQL

[Francisco Olarte]

Buenos dias:

2015-10-24 0:03 GMT+02:00 Carlos Joaniquet <cjtam...@yahoo.es>:
> Me gustaría saber si desde un programa cliente puedo desactivar y activar un 
> trigger o constraint desde sentencia SQL para realizar alguna tarea de 
> mantenimiento.

¿ A que le llamas un programa cliente ? El psql es un prgrama cliente,
el pgadmin otro y una aplicacion en java usando JDBC, p.e., otro.
Todos se comunican con la BD por un socket, al servidor le da igual.
De hecho el pgrestore es otro programa cliente que hace cosas de esas
mientras restaura, y las hace de la misma forma que cualquier otra
aplicacion, mandando cosas por un socket.

> Por otro lado, a nivel informativo y que nada tiene  que ver, si todo me va 
> como un tiro, me conviene pasar de versión 9.1 a 9.3? Hay que hacer muchos 
> cambios?

Yo te recomendaria, si te vas a liar, pasar a la 9.4 ( que ya esta mas
testeadita y te dara mas tiempo antes de ser declarada fuera de
soporte )  ( o esperar a la 9.5 ). Yo cambie de 9.1 a 9.3 sin
problemas ( solo la ventana de mantenimiento para tener tiempo a hacer
dump/restore ). Lo que es mas critico en estas cosas suele ser si
puedes parar el sistema un rato para mover las cosas con calma, es
decir, dependes del tamaño de la BD mas que otra cosa, sin saber el
tiempo que tardarias en hacerlo y la posibilidad de parar es dificil
recomendar naa.

Si tu setup te lo permite intenta restaurar un backup en una maquina
de pruebas y probar las aplicaciones, asi como medir el tiempo que
tardas en hacer un backup + restore, y aprendete como hacer restores
rapidos ( lo clasico, minimo log, fsync off, buena cantidad de buffers
porque solo hay un proceso tocando ).

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

Re: [pgsql-es-ayuda] Ayuda sobre consulta!!!!

[Francisco Olarte]

Flavio:

2015-10-22 14:58 GMT+02:00 Flavio Roche <fero...@uci.cu>:
> Les escribo porque tengo la siguiente problemática, tengo una tabla persona
> la cual cuenta con la siguiente estructura
> CREATE TABLE persona
> (
>   pasaporte integer,
>   nombre text,
>   calificacion integer,
>   fecha text,
>   acumula boolean
> )
>
> Y pongo un ejemplo de los datos que tengo almacenados en la misma
>
> pasaportenombre  calificacion fecha
> acumula
>   1 Pepe 4 12/10/2015 
>  t
>   2 Jose  513/10/2015 
>  f
>   1 Pepe 312/11/2015  
> t
>   3 Ramon 5 14/10/2015
>   t
>   2 Jose  313/11/2015 
>  f

> Necesito hacer una funcion que se le pase por parámetro un rango de fecha, y
> calcule la calificación promedio de las personas en ese intervalo de tiempo
> en caso de que el parámetro acumula tenga valor true y en caso que no
> acumule, la última calificación obtenida. Ejemplo de la salida deseada
> al llamar ejecutar la funcion..
> Select * from consulta('01/10/2015','25/11/2015')
>
> 1   Pepe3.5 (acumula)
> 2   Jose 3  (No acumula)
> 3   Ramon 5  (Acumula)

Aqui le veo un problema gordo, tu tabla parece estar desnormalizada y
sin restricciones ( es decir, Jose podria tener pasaportes 2 y 22 , y
pepe podria tener acumula t y f, y Ramon pasaporte y acumula a null.
Esto hace que la funcion sea enormemente compleja. Para reducirlo un
poco te comento sobre una estructura equivalente pero normalizada en
dos tablas, persona ( pasaporte primary key, nombre not null, acumula
not null) y calificaciones ( pasaport foreign key references persona,
calificacion not null, fecha not null).

Otro problema gordo es que metes FECHA como texto, malo, y encima en
DD/MM/, peor ( los que venimos de la epoca de las tarjetas, y
ademas seguimos usando archivos de texto plano, sabemos que las fechas
es mejor guardarlas como numeros de 8 digitos o textos de 8 o 10
caracteres pero con la forma  (A*100+M)*100+D  o  '/MM/DD' para
que el sort natural del campo ordene por fecha automaticamente.
Supondre tambien que puedes corregir eso.

En ese caso con una funcion en cualquier lenguage no es dificil ( no
hay mas que hacer dos select ordenados o con joins y barrer), incluso
con las funciones de ventana creo que se podria hacer en un solo
query.

Para eso usas un truco tipico, que es empezar por calcular las dos
cosas en la tabla de calificaciones, la media es facil,
avg(calificacion*1.0), o avg(calificacion::real) ( otro problema en tu
modelo de datos calificacion es integer pero la media la quieres con
decimales ). el ultimo valor creo que se saca con
last_value(calificacion) over (group by fecha, order by fecha), o algo
asi, no tengo accesible donde probarlo en este momento pero no deberia
ser dificil. Supongamos que tu query es:

select pasaporte,
avg(calificacion::real) as media,
last_value(calificacion::real) over ( group by pasaporte order by
fecha) as ultima
from calificaciones
group by pasaporte

Ya solo tienes que hacer un join con personas para sacar las cosas.
Con un CTE es facil:

with aux as (
select pasaporte,
avg(calificacion::real) as media,
last_value(calificacion::real) over ( group by pasaporte order by
fecha) as ultima
from calificaciones
group by pasaporte
)
select
   per.pasaporte,
   per.name,
   case when per.acumula then media else ultima end,
   case when per.acumule then "(acumula)" else "(No acumula)" end
from aux, personas per
where aux.pasaporte = per.pasaporte
order by pasaporte

Esto seria mas o menos si normalizas las tablas y usas fechas. Si no
puedes hacer algo similar con tu tabla original en varios pasos(
usando CTE o select sobre select sobre select), empieza por
seleccionar un to_date del fecha, para tener los ordenes correctos.
Sobre este resultado haz el equivalente al primer query, pero añade
los valores de nombre y pasaporte ( usa max(nombre), max(pasaporte),
p.e., ya que es un query agregado, sobre este ultimo haz el case para
formatear / seleccionar. Una vez que los tengas todos puedes
simplificarlo a un unico query, pero te saldra complicado.

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