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

[Ruben avila galindo]

Hola amigos queria saber si puedo hacer una funcion en PostgreSQL pero que
en la funcion actualize una BD de SQL SERVER.
espero alguna ayuda.

create function sp_actualizar_stock

parametreos entrada

- Producto
- Stock

Update Tabla Postgresql

Update Table en SQL SERVER


Saludos.





Ruben Avila G.
Ing.Sistemas
Developer y Arquitecto Opensource
Cel:997686960

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

[Francisco Olarte]

2017-03-16 19:46 GMT+01:00 Maria Antonieta Ramirez :
> 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] Encontrar una manera menos intensiva de hacer una consulta

[Gunnar Wolf]

Alvaro Herrera dijo [Tue, Mar 14, 2017 at 04:07:35PM -0300]:
> > Creo que con esto podemos seguir trabajando. ¡A estudiar funciones
> > sobre arreglos!
> 
> Creo que lo que más te puede ayudar en este caso es "scalar op array
> expression", donde tienes un valor escalar, un operador, y un array.
> No sé si hay más casos que estos dos:
> 
> escalar = ANY (array)
> escalar <> ALL (array)
> el operador puede ser cualquier cosa, no solo = o <>;
> el escalar puede ser una columna de una tabla.
> 
> La primera retorna TRUE si cualquier elemento del array es igual al
> escalar.  La segunda retorna TRUE si todos los elementos del array son
> <> al escalar.
> 
> El "scalar op array expr" es un caso específicamente optimizado --
> particularmente con btrees.

OK, si está específicamente optimizado, buscaré utilizarlo. Por ahora,
hice un par de consultas (que me dejaron satisfecho) especificando mi
escalar explícitamente como arreglo. Obviamente sucio, porque sólo
estoy jugando:

 SELECT * FROM (
SELECT email, array_agg(show_keyid(keyid)) AS keys,
   cardinality(array_agg(show_keyid(keyid))) as numkeys
FROM pubkey_metadata GROUP BY email) AS set
 WHERE keys && array['673a03e4c1db921f'];

 SELECT * FROM (
SELECT email, array_agg(show_keyid(keyid)) AS keys,
   cardinality(array_agg(show_keyid(keyid))) as numkeys
FROM pubkey_metadata GROUP BY email) AS set
 WHERE '673a03e4c1db921f' = ANY(keys);

Comparando sus query plans y tiempos de ejecución me parecen casi
sinónimos. Pero, sí, la versión con ANY resulta un poco más legible y
clara para el humano, que no es poca cosa :)

(¿que por qué usé un subquery para algo tan trivial como esto? Porque
si no, el ANY(keys) se quejaba de que keys no existía, y no puedo
incluir una función en el WHERE).


-
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] migracion de versiones

[Maria Antonieta Ramirez]

Buena tarde


Por medio del presente contacto a ustedes 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.


Sin mas por el momento quedo a sus órdenes para cualquier duda o comentario.


Gracias.

Re: [pgsql-es-ayuda] Encontrar una manera menos intensiva de hacer una consulta

[Gunnar Wolf]

Alvaro Herrera dijo [Tue, Mar 14, 2017 at 02:35:26PM -0300]:
> > OK, interesante consejo, y tiene algo de sentido. Sin embargo... Se ve
> > que tengo que hacer algo de trabajo antes de implementarlo, porque,
> > con 8.5GB libres (y una BD que ocupa 6.6G),
> 
> Hmm, 6.6 GB para unos cuantos keyring?  Suena excesivo ...

Realmente suena excesivo. :-( Sobre todo si no me estoy yendo sobre la
más gorda de mis tablas (signatures, 37 millones), sino sobre una
"sencillita" - Pero como sea, está haciendo un join sobre sí misma de
más de un millón de registros.

> Noté recién que tienes ORDER BY en las definiciones de algunas vistas, los
> cuales yo también quitaría, a menos que el orden tenga importancia (que
> no me lo parece).

Claro. Bueno, yo le sugería a Víctor (que hizo parte interesante de
las uniones entre estas vistas) evitar hacer composiciones de vistas;
no se me había ocurrido este corolario... Pero, sí, saqué los ORDER BY
también. 

> Creo que gran parte del problema son está en esta vista y
> people_metadata:
> (...)
> Acá te recomendaría quitar el ORDER BY, que no te está haciendo ningún
> favor.  Es mejor aplicar ORDER BY al resultado final, al consultar la
> vista.

Leí hasta acá tu correo. Volví a generar las vistas sacando el ORDER
BY. Mandé de vuelta el EXPLAIN ANALIZE. Y... Mi corazón sufrió una
triste desazón por casi media hora, para encontrarme con esto:

   
QUERY PLAN  
  
-
 Merge Join  (cost=561450.65..1317.57 rows=710016061 width=104) (actual 
time=23286.968..1162335.210 rows=471044420 loops=1)
   Merge Cond: (u.email = u_1.email)
   Join Filter: (k.keyid <> k_1.keyid)
   Rows Removed by Join Filter: 172082068
   ->  Sort  (cost=230941.32..234107.60 rows=1266510 width=28) (actual 
time=14177.487..15791.991 rows=1266332 loops=1)
 Sort Key: u.email
 Sort Method: external merge  Disk: 46904kB
 ->  Hash Join  (cost=507.53..72262.16 rows=1266510 width=28) (actual 
time=111.209..9700.968 rows=1266332 loops=1)
   Hash Cond: (ptu.userid_id = u.id)
   ->  Hash Join  (cost=184.65..40276.53 rows=1266510 width=12) 
(actual time=41.664..7400.240 rows=1266332 loops=1)
 Hash Cond: (ptu.pubkey_id = k.id)
 ->  Seq Scan on pubkey_tag_userid ptu  
(cost=0.00..19511.10 rows=1266510 width=8) (actual time=0.006..5487.610 
rows=1266332 loops=1)
 ->  Hash  (cost=143.62..143.62 rows=3282 width=12) (actual 
time=41.635..41.635 rows=3293 loops=1)
   Buckets: 1024  Batches: 1  Memory Usage: 142kB
   ->  Hash Join  (cost=37.67..143.62 rows=3282 
width=12) (actual time=0.434..39.120 rows=3293 loops=1)
 Hash Cond: (k.pk_algorithm_id = a.id)
 ->  Seq Scan on pubkey k  (cost=0.00..60.82 
rows=3282 width=16) (actual time=0.004..34.232 rows=3293 loops=1)
 ->  Hash  (cost=22.30..22.30 rows=1230 
width=4) (actual time=0.403..0.403 rows=21 loops=1)
   Buckets: 1024  Batches: 1  Memory Usage: 
1kB
   ->  Seq Scan on pk_algorithm a  
(cost=0.00..22.30 rows=1230 width=4) (actual time=0.351..0.377 rows=21 loops=1)
   ->  Hash  (cost=196.28..196.28 rows=10128 width=24) (actual 
time=69.515..69.515 rows=10141 loops=1)
 Buckets: 1024  Batches: 1  Memory Usage: 557kB
 ->  Seq Scan on userid u  (cost=0.00..196.28 rows=10128 
width=24) (actual time=0.005..61.607 rows=10141 loops=1)
   ->  Materialize  (cost=330509.32..336841.87 rows=1266510 width=96) (actual 
time=9109.461..382175.721 rows=643126484 loops=1)
 ->  Sort  (cost=330509.32..333675.60 rows=1266510 width=96) (actual 
time=9109.450..10711.784 rows=1266332 loops=1)
   Sort Key: u_1.email
   Sort Method: external merge  Disk: 118560kB
   ->  Hash Join  (cost=507.53..72262.16 rows=1266510 width=96) 
(actual time=25.016..5006.797 rows=1266332 loops=1)
 Hash Cond: (ptu_1.userid_id = u_1.id)
 ->  Hash Join  (cost=184.65..40276.53 rows=1266510 
width=60) (actual time=9.596..2797.348 rows=1266332 loops=1)
   Hash Cond: (ptu_1.pubkey_id = k_1.id)
   ->  Seq Scan on pubkey_tag_userid ptu_1  
(cost=0.00..19511.10 rows=1266510 width=8) (actual time=0.013..872.220 
rows=1266332 loops=1)
   ->  Hash  (cost=143.62..143.62 rows=3282 width=60) 
(actual time=9.550..9.550 rows=3293 loops=1)
 Buckets: 1024  Batches: 1  Memory Usage: 

Re: [pgsql-es-ayuda] Encontrar una manera menos intensiva de hacer una consulta

[Gunnar Wolf]

Alvaro Herrera dijo [Tue, Mar 14, 2017 at 08:54:58AM -0300]:
> > Ahora bien... El "objeto de estudio" fundamental no debería ser la
> > llave, sino que la persona. Determinamos que una persona está definida
> > por una o más llaves con la misma dirección de correo.
> > 
> > No se si el problema sea la cantidad de datos o nuestra inexperiencia
> > desarrollando consultas medianamente complejas... Pero este «EXPLAIN
> > ANALYZE SELECT * FROM people_metadata» me suena a
> > grosería. Obviamente, no es algo que quiero lanzar a cada consulta.
> 
> ¿Por qué las definiciones de las vistas tienen DISTINCT?  Creo que eso
> puede explicar gran parte del problema.  Me parece que lo ideal sería
> eliminar completamente el uso de DISTINCT, lo cual puede significar que
> agregues restricciones adicionales en algunas tablas para asegurar
> unicidad, o alguna otra modificación al esquema.

OK, interesante consejo, y tiene algo de sentido. Sin embargo... Se ve
que tengo que hacer algo de trabajo antes de implementarlo, porque,
con 8.5GB libres (y una BD que ocupa 6.6G), regeneré las tres vistas
en cuestión (people_metadata, pubkey_metadata,
pubkey_metadata_equivalence) quitando los DISTINCT, y

keyring=>  select distinct * from people_metadata_b;
ERROR:  could not write block 1060433 of temporary file: No space left on 
device

:-(

-
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] Encontrar una manera menos intensiva de hacer una consulta

[Gunnar Wolf]

Fernando Romo dijo [Mon, Mar 13, 2017 at 08:49:34PM -0600]:
> Deja te platico:
> 
> para un proyecto de facturación electrónica, tenía que analizar unos
> 26 millones de CFDI’s en formato XML y buscar información que
> pudiera representar en grafiquitas bonitas y de manera “instantanea”
> por lo cual en lugar de hacer super querys hice lo siguiente:
> 
> 1) Crear un conjunto de tablas que son un cache de la información de
> manera dinámica (...)
> 
> 2) definiendo el punto 1, hice un algoritmo sencillo que le puse el
> nombre mamón de “cache diferencia”, con lo cual hago cortes de pocas
> tuplas, para ir propagando la información.
> 
> El proceso es el siguiente:
> (...)
> 6) si “cacheas” tu mega query y lo fragmentas en ventanas mas
> pequeñas, puedes alimentar una tabla de cavche intermediaria que
> puede ser actualizada de manera dinámica.
> 
> 7) y saco este tipo de reportes:

Sí, platicaba con Víctor, y esta era una de las sugerencias originales
que teníamos. Pero bueno... Me conoces, soy terco y purista... E
insistí en que busquemos una alternativa más limpia y que no lleve a
desfasar la realidad y los datos. Pero dada la naturaleza de nuestra
información... no suena descabellado hacer un corte diario y
actualizar nuestros cachés.

En fin, me mantengo al pendiente en caso de haber alguna otra
recomendación por esta vía. ¡Gracias!


signature.asc
Description: Digital signature

Re: [pgsql-es-ayuda] Consulta DBLink

[Anthony Sotolongo]

Hola Alberto, coincido con Francisco que puedes tener problemas con las 
comillas y la concatenación.


Por otro lugar,  si utilizas postgres 9.3 o +, recomiendo la posibilidad 
de  analizar el  uso de los FDW( 
https://www.postgresql.org/docs/9.6/static/postgres-fdw.html ) que puede 
resultar mejor y más cómodo.



Saludos



On 18/03/17 06:57, Francisco Olarte wrote:

Alberto:

2017-03-18 5:02 GMT+01:00 Alberto Cardenas Cardenas
:

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



-
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