Re: [pgbr-geral] VELOCIDADE DE ACESSO REMOTO AO POSTGRESQL

2016-03-08 Por tôpico itamar 
Apesar de REST ser moderno e flexibilizar a interoperabilidade não sei 
se resolveria o problema levantado pelo autor original da thread, até 
mesmo porque o payload do REST, por conta do JSON, é maior do que da 
libpq. Att,


sem rest  = 1 conexão para cada usuario

com rest o servidor web pode utilizar um pool de conexões com o banco


___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] VELOCIDADE DE ACESSO REMOTO AO POSTGRESQL

2016-03-08 Por tôpico itamar 



Certamente... mas creio que um pool de conexões irá ajudar o colega a
diminuir a latencia já mencionada pelo Alexsander na negociação via libpq.

Att,



rest = pool de conexões entre o webserver e o banco


conexão via libpq= 1 conexão por cliente.

___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] VELOCIDADE DE ACESSO REMOTO AO POSTGRESQL

2016-03-08 Por tôpico Itamar Reis Peixoto 


Uma dica, já usei e funciona muito bem: zebedee.



software velho e ultrapassado, recomendo utilizar stunnel no lugar.

___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] VELOCIDADE DE ACESSO REMOTO AO POSTGRESQL

2016-03-08 Por tôpico Jean 
 

> Em 05.03.2016 16:10, Ali do Amaral Pedrozo escreveu:

> Olá! 
> 
>
Sou iniciante no Postgres! Tenho uma aplicação em SQL SERVER 2014
EXPRESS desenvolvida em Delphi XE 8 e estou migrando para o Postgres
9.4. 
> 
> No ambiente de testes funciona tudo perfeitamente, porém,
quando eu me conecto em um Postgres remoto (instalado em um Debian 8 ),
a conexão, e a recuperação de dados é lenta. 
> 
> Informações gerais do
ambiente remoto: 
> - Servidor: Debian 8 
> - Banco: Postgres 9.4 +
postgis 
> - Banda: 4MB ADSL 
> - pg_hba.conf (acrescentei apenas essa
linha para acesso remoto) 
> 
> host all all 177.42.58.148/32 [1] md5 
>

> - postgres.conf (alterei somente esta linha para acessar remoto) 
>
listen_addresses = '*' 
> 
> Informações gerais do ambiente onde está
minha aplicação em Delphi: 
> - Windows 8.1 
> - Banda 15 MB ADSL 
> 
>
Alguns testes que eu já fiz: 
> 1) no pgadmin, se eu faço select * from
compra (tenho 18 campos) com a tabela zerada, ele apresenta 301 ms,
porém, demora 21s para exibir a informação 
> 2) via psql no windows, 
>
psql -h xxx.xxx.xxx.xxx -U postgres (demora 2 s) 
> connect database
(demora 2s) 
> select * from compra; (instantaneo) 
> 3) via delphi,
conectando via firedac (demora 5s) 
> 4) via delphi, quando eu faço
tfdquery.open (demora 5s) 
> 
> Estou desconfiado que a lentidão vem do
componente que estou usando no delphi, o Firedac. 
> Alguem já teve este
problema ? 
> 
> Agradeço desde já!

Uma dica, já usei e funciona muito
bem: zebedee.

Atenciosamente,

Jean Domingues - Sócio
Proprietário
GECONTROL Consultoria e Sistemas
Fone (44) 3423-4250 /
8425-5418
www.gecontrolsistemas.com.br
 

Links:
--
[1]
http://177.42.58.148/32
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] VELOCIDADE DE ACESSO REMOTO AO POSTGRESQL

2016-03-08 Por tôpico Fabrízio de Royes Mello 
On 08-03-2016 15:29, Ivo Sestren Junior wrote:
> Tem que analisar bem isto.
> Mas se conectar diretamente via internet, tem o problema que estais
> liberando a base diretamente para a internet.

Com certeza... mas ai é outro ponto a discutir. Segurança!


> Além do que o protocolo necessita conectar/autenticar/enviar a
> consulta/enviar a requisição dos tipos (que o delphi faz), para ai então
> pegar o resultado. O que pode estar em um formato que ocuparia uma banda
> muito maior que REST.

O delphi faz requisição dos tipos? Até onde conheço os drivers que
manipulam a libpq naõ fazem isso.

Se algum driver/componete faz isso então está fazendo trabalho dobrado
pois isso vem embutido no ResultSet da PQExec [1] onde vc pode usar
PQnfields/PQfname/PQftype [2].


> Não conheço todos os detalhes do protocolo do postgresql, mas são muitos
> pontos a serem considerados.
> O melhor mesmo seria efetuar alguns testes dentro do seu ambiente;
> 

Certamente... mas creio que um pool de conexões irá ajudar o colega a
diminuir a latencia já mencionada pelo Alexsander na negociação via libpq.

Att,

[1] http://www.postgresql.org/docs/current/static/libpq-example.html
[2] http://doxygen.postgresql.org/libpq-fe_8h.html

-- 
   Fabrízio de Royes Mello Timbira - http://www.timbira.com.br/
   PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento



signature.asc
Description: OpenPGP digital signature
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] VELOCIDADE DE ACESSO REMOTO AO POSTGRESQL

2016-03-08 Por tôpico Ivo Sestren Junior 
Tem que analisar bem isto.
Mas se conectar diretamente via internet, tem o problema que estais
liberando a base diretamente para a internet.
Além do que o protocolo necessita conectar/autenticar/enviar a
consulta/enviar a requisição dos tipos (que o delphi faz), para ai então
pegar o resultado. O que pode estar em um formato que ocuparia uma banda
muito maior que REST.
Não conheço todos os detalhes do protocolo do postgresql, mas são muitos
pontos a serem considerados.
O melhor mesmo seria efetuar alguns testes dentro do seu ambiente;

Em 8 de março de 2016 14:13, Fabrízio de Royes Mello <
fabri...@timbira.com.br> escreveu:

> On 08-03-2016 12:38, Guimarães Faria Corcete DUTRA, Leandro wrote:
> > 2016-03-08 10:53 GMT-03:00 Fabrízio de Royes Mello <
> fabri...@timbira.com.br>:
> >>
> >> Pq? O payload do REST é maior que da libpq...
> >
> > Fabrízio, poderia explicar-nos o que constituiria a tal ‘carga paga’
> > de cada uma?
> >
>
> Com REST no retorno é necessário montar um JSON com vários elementos a
> mais (payload) que um retorno da libpq [1] não tem, pois apenas tem
> alguns caracteres de controle e os dados resultantes do SELECT.
>
> Att,
>
>
> [1] http://www.postgresql.org/docs/current/static/libpq.html
>
> --
>Fabrízio de Royes Mello Timbira - http://www.timbira.com.br/
>PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento
>
>
> ___
> pgbr-geral mailing list
> pgbr-geral@listas.postgresql.org.br
> https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
>
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] VELOCIDADE DE ACESSO REMOTO AO POSTGRESQL

2016-03-08 Por tôpico Fabrízio de Royes Mello 
On 08-03-2016 12:38, Guimarães Faria Corcete DUTRA, Leandro wrote:
> 2016-03-08 10:53 GMT-03:00 Fabrízio de Royes Mello :
>>
>> Pq? O payload do REST é maior que da libpq...
> 
> Fabrízio, poderia explicar-nos o que constituiria a tal ‘carga paga’
> de cada uma?
> 

Com REST no retorno é necessário montar um JSON com vários elementos a
mais (payload) que um retorno da libpq [1] não tem, pois apenas tem
alguns caracteres de controle e os dados resultantes do SELECT.

Att,


[1] http://www.postgresql.org/docs/current/static/libpq.html

-- 
   Fabrízio de Royes Mello Timbira - http://www.timbira.com.br/
   PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento



signature.asc
Description: OpenPGP digital signature
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Paradas na replicação do PostgreSQL - Diagnóstico

2016-03-08 Por tôpico Euler Taveira 
On 08-03-2016 12:40, Everton Berz wrote:
> Eu quis dizer que os parâmetros estão comentados no primário. No standby
> são aqueles valores que informei.
>
No primário, max_standby_*_delay não tem efeito; eles valem no
secundário. Isso confirma a minha teoria que os atrasos são ocasionados
pelas consultas de longa duração.

> Sobre não haver cancelamento de consultas, essa é a política adotada, é
> uma exigência da aplicação/negócio.
> 
Se quiserem uma replicação sem atraso, você vai precisar de outro
servidor com os valores igual a zero ou mesmo que não aceite consultas.


-- 
   Euler Taveira   Timbira - http://www.timbira.com.br/
   PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] VELOCIDADE DE ACESSO REMOTO AO POSTGRESQL

2016-03-08 Por tôpico Fabrízio de Royes Mello 
Por favor, evite top-posting!

On 08-03-2016 11:37, Alexsander Rosa wrote:
> Em termos de libpq, tem latência no PQconnectdb, no PQstatus, no PQexec,
> etc... se você se conecta a um host remoto, cada ida-e-volta em cada
> comando desses leva vários milissegundos. Se for um webservice você
> conecta, o webservice se conecta ao PG numa LAN e faz tudo isso com uma
> latência bem menor, depois te responde somente o payload. Se for um
> componente "curioso" que faz uns SELECT a mais, é pior ainda.
> 

Sua resposta reforça mais ainda minha desconfiança se realmente um REST
para o cenário proposto irá melhorar.

Com REST vc terá outro ponto de requisição além da libpq, porque será:

client > HTTP Request/Response > libpq > PostgreSQL

E ainda coloquei uma situação minimalista supondo que a requisicao HTTP
interaja diretamente com a libpq, o que não é possível pois sempre
existirá "alguém" fazendo isso para vc (aka sua linguagem de programação
e/ou app server).

De qualquer forma para minimizar a latência que a libpq pode impor,
através de seus métodos (como vc mencionou), é possível utilizar um pool
de conexoes [1] local entre o client e o server. Dessa forma basicamente
será trafegado dados pela PQExec.

Att,


[1] http://pgbouncer.github.io/
-- 
   Fabrízio de Royes Mello Timbira - http://www.timbira.com.br/
   PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento



signature.asc
Description: OpenPGP digital signature
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Paradas na replicação do PostgreSQL - Diagnóstico

2016-03-08 Por tôpico Everton Berz 
2016-03-08 12:33 GMT-03:00 Euler Taveira :

> On 07-03-2016 14:55, Everton Berz wrote:
> > Primário: os parâmetros max_standby.. estão comentados
> > Standby:
> > #max_standby_archive_delay = 30s
> > max_standby_archive_delay = -1
> > max_standby_streaming_delay = -1
> >
> Eu não entendi... Acima parece descomentados mas você está dizendo que
> estão comentados. O padrão é 30s mas -1 significa que *não* há
> cancelamento de consultas, ou seja, haverá um atraso em aplicar a
> replicação causado pelas consultas longas.
>
> Os parâmetros max_standby_*_delay controlam exatamente a tolerância (i)
> para cancelamento de consultas ou (ii) para atraso na replicação. -1
> significa não cancele consultas e atrase a replicação (se necessário). 0
> significa não atrase a replicação e cancele consultas (se necessário).
>
> O log em anexo não indica que estar havendo "parada" da replicação (o
> LSN está aumentando).
>
>
Eu quis dizer que os parâmetros estão comentados no primário. No standby
são aqueles valores que informei.
Sobre não haver cancelamento de consultas, essa é a política adotada, é uma
exigência da aplicação/negócio.



> > Estamos planejando migrar para 9.5.1.
> >
> A migração para uma nova versão é mais demorada porque deve haver
> homologação e/ou adaptação da aplicação. Ao invés disso, você poderia
> instalar a 9.3.11 (última versão corretiva da 9.3) para não ter
> problemas com bugs conhecidos. A atualização *não* implica em novas
> funcionalidades ou alteração de comportamento e para fazê-la basta
> atualizar os binários e reiniciar o serviço.
>


Ok, vamos analisar isso.
Obrigado!
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] VELOCIDADE DE ACESSO REMOTO AO POSTGRESQL

2016-03-08 Por tôpico Guimarães Faria Corcete DUTRA , Leandro 
2016-03-08 10:53 GMT-03:00 Fabrízio de Royes Mello :
>
> Pq? O payload do REST é maior que da libpq...

Fabrízio, poderia explicar-nos o que constituiria a tal ‘carga paga’
de cada uma?



-- 
skype:leandro.gfc.dutra?chat  Yahoo!: ymsgr:sendIM?lgcdutra
+55 (61) 3546 7191  gTalk: xmpp:leand...@jabber.org
+55 (61) 9302 2691ICQ/AIM: aim:GoIM?screenname=61287803
BRAZIL GMT−3  MSN: msnim:chat?contact=lean...@dutra.fastmail.fm
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Paradas na replicação do PostgreSQL - Diagnóstico

2016-03-08 Por tôpico Euler Taveira 
On 07-03-2016 14:55, Everton Berz wrote:
> Primário: os parâmetros max_standby.. estão comentados
> Standby: 
> #max_standby_archive_delay = 30s
> max_standby_archive_delay = -1
> max_standby_streaming_delay = -1
> 
Eu não entendi... Acima parece descomentados mas você está dizendo que
estão comentados. O padrão é 30s mas -1 significa que *não* há
cancelamento de consultas, ou seja, haverá um atraso em aplicar a
replicação causado pelas consultas longas.

Os parâmetros max_standby_*_delay controlam exatamente a tolerância (i)
para cancelamento de consultas ou (ii) para atraso na replicação. -1
significa não cancele consultas e atrase a replicação (se necessário). 0
significa não atrase a replicação e cancele consultas (se necessário).

O log em anexo não indica que estar havendo "parada" da replicação (o
LSN está aumentando).

> Estamos planejando migrar para 9.5.1.
> 
A migração para uma nova versão é mais demorada porque deve haver
homologação e/ou adaptação da aplicação. Ao invés disso, você poderia
instalar a 9.3.11 (última versão corretiva da 9.3) para não ter
problemas com bugs conhecidos. A atualização *não* implica em novas
funcionalidades ou alteração de comportamento e para fazê-la basta
atualizar os binários e reiniciar o serviço.


-- 
   Euler Taveira   Timbira - http://www.timbira.com.br/
   PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] replicação bidirecional

2016-03-08 Por tôpico Euler Taveira 
On 08-03-2016 09:22, Euler Garcia - PoçosNet wrote:
> Já utilizo o BDR, porém aquela versão modificada. Fiz algumas
> leituras e não entendi muito bem, na versão 9.5 o BDR já foi incorporado
> na versão oficial?
> 
Não.


PS> não sequestre um assunto. Se é uma pergunta nova, crie um email novo
ao invés de responder a uma discussão em aberto. Isso bagunça o
histórico da lista.


-- 
   Euler Taveira   Timbira - http://www.timbira.com.br/
   PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] VELOCIDADE DE ACESSO REMOTO AO POSTGRESQL

2016-03-08 Por tôpico Alexsander Rosa 
Em termos de libpq, tem latência no PQconnectdb, no PQstatus, no PQexec,
etc... se você se conecta a um host remoto, cada ida-e-volta em cada
comando desses leva vários milissegundos. Se for um webservice você
conecta, o webservice se conecta ao PG numa LAN e faz tudo isso com uma
latência bem menor, depois te responde somente o payload. Se for um
componente "curioso" que faz uns SELECT a mais, é pior ainda.

Em 8 de março de 2016 10:53, Fabrízio de Royes Mello <
fabri...@timbira.com.br> escreveu:

> On 08-03-2016 10:38, Alexsander Rosa wrote:
> > Em 5 de março de 2016 16:10, Ali do Amaral Pedrozo  > > escreveu:
> >
> >
> > Informações gerais do ambiente onde está minha aplicação em Delphi:
> > - Windows 8.1
> > - Banda 15 MB ADSL
> >
> > Alguns testes que eu já fiz:
> > 1) no pgadmin, se eu faço select * from compra (tenho 18 campos) com
> > a tabela zerada, ele apresenta 301 ms, porém, demora 21s para exibir
> > a informação
> > 2) via psql no windows,
> > psql -h xxx.xxx.xxx.xxx -U postgres (demora 2 s)
> > \connect database (demora 2s)
> > select * from compra; (instantaneo)
> > 3) via delphi, conectando via firedac (demora 5s)
> > 4) via delphi, quando eu faço tfdquery.open (demora 5s)
> >
> >
> > Tem toda uma latência envolvida (em várias fases). Use REST.
> >
>
> Pq? O payload do REST é maior que da libpq...
>
> --
>Fabrízio de Royes Mello Timbira - http://www.timbira.com.br/
>PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento
> ___
> pgbr-geral mailing list
> pgbr-geral@listas.postgresql.org.br
> https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
>



-- 
Atenciosamente,
Alexsander da Rosa
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Relação de leitura x escrita

2016-03-08 Por tôpico Euler Taveira 
On 08-03-2016 08:51, Cleiton Luiz Domazak wrote:
> Preciso saber a relação de leituras x escritas no banco.
> 
Veja a visão pg_statio_user_tables.

> 2- Existe alguma visão que me mostre a quantidade de SELECT, UPDATE,
> DELETE, INSERT, e não a quantidade de linhas envolvidas?
> 
pg_stat_user_tables: n_tup_ins, n_tup_upd, n_tup_del


-- 
   Euler Taveira   Timbira - http://www.timbira.com.br/
   PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] VELOCIDADE DE ACESSO REMOTO AO POSTGRESQL

2016-03-08 Por tôpico Fabrízio de Royes Mello 
On 08-03-2016 10:38, Alexsander Rosa wrote:
> Em 5 de março de 2016 16:10, Ali do Amaral Pedrozo  > escreveu:
> 
> 
> Informações gerais do ambiente onde está minha aplicação em Delphi:
> - Windows 8.1
> - Banda 15 MB ADSL
> 
> Alguns testes que eu já fiz:
> 1) no pgadmin, se eu faço select * from compra (tenho 18 campos) com
> a tabela zerada, ele apresenta 301 ms, porém, demora 21s para exibir
> a informação
> 2) via psql no windows,
> psql -h xxx.xxx.xxx.xxx -U postgres (demora 2 s)
> \connect database (demora 2s)
> select * from compra; (instantaneo)
> 3) via delphi, conectando via firedac (demora 5s)
> 4) via delphi, quando eu faço tfdquery.open (demora 5s)
> 
> 
> Tem toda uma latência envolvida (em várias fases). Use REST.
>  

Pq? O payload do REST é maior que da libpq...

-- 
   Fabrízio de Royes Mello Timbira - http://www.timbira.com.br/
   PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] VELOCIDADE DE ACESSO REMOTO AO POSTGRESQL

2016-03-08 Por tôpico Alexsander Rosa 
Em 5 de março de 2016 16:10, Ali do Amaral Pedrozo 
escreveu:

>
> Informações gerais do ambiente onde está minha aplicação em Delphi:
> - Windows 8.1
> - Banda 15 MB ADSL
>
> Alguns testes que eu já fiz:
> 1) no pgadmin, se eu faço select * from compra (tenho 18 campos) com a
> tabela zerada, ele apresenta 301 ms, porém, demora 21s para exibir a
> informação
> 2) via psql no windows,
> psql -h xxx.xxx.xxx.xxx -U postgres (demora 2 s)
> \connect database (demora 2s)
> select * from compra; (instantaneo)
> 3) via delphi, conectando via firedac (demora 5s)
> 4) via delphi, quando eu faço tfdquery.open (demora 5s)
>
>
Tem toda uma latência envolvida (em várias fases). Use REST.



-- 
Atenciosamente,
Alexsander da Rosa
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] VELOCIDADE DE ACESSO REMOTO AO POSTGRESQL

2016-03-08 Por tôpico Fabrízio de Royes Mello 
On 05-03-2016 18:31, Itamar Reis Peixoto wrote:
> 
> 
> On 03/05/2016 05:28 PM, Fabrízio de Royes Mello wrote:
>> On 05-03-2016 16:21, Itamar Reis Peixoto wrote:
>>> On 2016-03-05 04:10 PM, Ali do Amaral Pedrozo wrote:
 Olá!

 Sou iniciante no Postgres! Tenho uma aplicação em SQL SERVER 2014
 EXPRESS desenvolvida em Delphi XE 8 e estou migrando para o Postgres
 9.4.

 No ambiente de testes funciona tudo perfeitamente, porém, quando eu
 me conecto em um Postgres remoto (instalado em um Debian 8 ), a
 conexão, e a recuperação de dados é lenta.
>>> acesse o banco atraves de REST.
>>>
>> Pq?
>>
> delphi é um a linguagem morta, rest é algo moderno, rápido, seguro,
> utilizando rest fica mais facil colocar algo na web caso seja necessario.
> 

Não vou comentar sobre Deplhi pois não quero polemizar (IMHO não está
morta não).

Apesar de REST ser moderno e flexibilizar a interoperabilidade não sei
se resolveria o problema levantado pelo autor original da thread, até
mesmo porque o payload do REST, por conta do JSON, é maior do que da libpq.

Att,

-- 
   Fabrízio de Royes Mello Timbira - http://www.timbira.com.br/
   PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento



signature.asc
Description: OpenPGP digital signature
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] replicação bidirecional

2016-03-08 Por tôpico Euler Garcia - PoçosNet 

Euler Bom dia,

Já utilizo o BDR, porém aquela versão modificada. Fiz algumas 
leituras e não entendi muito bem, na versão 9.5 o BDR já foi incorporado 
na versão oficial?


--
Atenciosamente,
Euler Thomas Garcia
Rede Sul Mineira de Provedores
euler.gar...@pocos-net.com.br


Em 23-02-2016 22:49, Euler Taveira escreveu:

On 23-02-2016 22:03, Fernanda Forbici wrote:

>Qual ferramenta, gratuita, vocês recomendam para replicação bidirecional?
>

Atualmente, bdr [1] ou bucardo [2].


>Pelo que li o slony não é aconselhavel para replicação bidirecional.
>

Se for replicar bancos de dados distintos, é possível usar o Slony
(seria uma replicação cruzada -- cada nó contém o mestre de um e o
escravo do outro). Contudo, se for o mesmo conjunto de tabelas, não
(neste caso você quer um replicação com múltiplos mestres).


>Vi também a ferramenta pg_replicator, mas ao que parece foi descontinuada??
>

Não conheço.


>Alguém tem material, com os passos para configurar a replicação
>bidirecional??
>

Replicação bidirecional ainda não é suportada pelo PostgreSQL. No
entanto, há um projeto chamado bdr [1] que está sendo integrado aos
poucos ao PostgreSQL. Ele possui a mesma licença de uso do PostgreSQL.
Funciona com versões a partir da 9.4 (mas eu aconselho utilizar com a
versão 9.5 -- senão você precisará de uma versão modificado da 9.4 para
que tudo funcione). Não utiliza gatilhos e sim o log de transação para
replicar os dados. Replica (quase todas) DDL. Não é suportado no Windows.

O Bucardo é um replicador assíncrono que pode ter múltiplos mestres.
Utiliza gatilhos para armazenar as mudanças. Não replica DDL. Não
funciona no Windows.


[1]http://2ndquadrant.com/en-us/resources/bdr/
[2]https://bucardo.org/


-- Euler Taveira Timbira - http://www.timbira.com.br/ PostgreSQL: 
Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento 
___ pgbr-geral mailing 
list pgbr-geral@listas.postgresql.org.br 
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral


___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

[pgbr-geral] Relação de leitura x escrita

2016-03-08 Por tôpico Cleiton Luiz Domazak 
Bom dia.

Talvez essa questão já tenha sido respondida mas não consegui encontrar na
lista.

Preciso saber a relação de leituras x escritas no banco. Hoje já utilizo o
pgBadger, onde consigo essa info facilmente, porém meu
log_min_duration_statement é de 75ms, acabo perdendo as que estão abaixo

Na pg_stat_database tenho o numero de linhas lidas e escritas, mas tenho 2
dúvidas ainda.

1- Faz sentido pegar as 2 colunas (tup_fetched + tup_returned)??

Em principio fiz dessa forma:

WITH totals AS
  (SELECT (tup_returned + tup_fetched) AS total_read,
  (tup_inserted + tup_updated+ tup_deleted) AS total_write
   FROM pg_stat_database
   WHERE datname = 'DBNAME')
SELECT total_read/total_write AS ratio
FROM totals

2- Existe alguma visão que me mostre a quantidade de SELECT, UPDATE,
DELETE, INSERT, e não a quantidade de linhas envolvidas?
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral