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

[Rafael Fialho]

Em 5 de março de 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)
>
> hostall all 177.42.58.148/32md5
>
> - 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)
>

As informações parecem meio desencontradas..
O pgadmin demora 21s para não exibir nada (ou existe dados?) e o firedac
demora 5s? Por que a demora seria no firedac, visto que o pgadmin demora
mais? E por que a diferença em relação ao psql? São ambientes
diferentes/testes diferentes?

Não consegui entender muito bem. O colega já conseguiu algum realizar algum
progresso?

Como já foi alertado por alguns, de certa forma, o firedac foi projetado
para aplicações client-server, e provavelmente não funcione tão bem para
bancos remotos, conectando de maneira direta e reta (como num ambiente
client-server), porém, cabe checar diversos outros tipos de problemas que
podem estar ocorrendo.

Se o colega pudesse dar algum retorno sobre seu progresso e seu ambiente,
para que a discussão possa auxiliá-lo, seria muito bacana.

[]'s
___
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 - OFF-TOPIC

[Flavio Henrique Araque Gurgel]

Não, foi alguém mais, o Gurgel só respondeu.  Leia as mensagens
anteriores antes de cantar de galo.


​Exatamente, porque você não le as mensagens anteriores, não estou
cantando de galo, sequer inferindo, ele escreveu com todas as letras. e
a oração me parecia bastante completa.


Oi Shander, desculpa aí se algo que falei não caiu bem, tá?

Eu não sou dono da verdade, ninguém é, tudo o que eu posto aqui é na 
intenção de ajudar. Ninguém ganha nada por ajudar nesta lista e o faz 
por prazer. Todo mundo tem seu emprego e ganha sua vida sem precisar 
aparecer, alguns com mais experiência, outros com menos.


Às vezes, a gente erra. Então esta discussão pra mim está encerrada e 
peço desculpas novamente se algo caiu "quadrado".


O resto do e-mail, eu cortei porque não interessa muito, e o teor está 
pesado.


Shander e Dutra, vocês estão fazendo ataques cruzados que não vão levar 
a lugar algum. Vamos todos parar e focar em ajudar ao próximo?


Abraços
Flavio
___
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

[Ivo Sestren Junior]

Já tentou utilizar o DataSnap do Delphi?
Bem fácil trabalhar com ele, tem até compressão de dados para transferência
via internet.
* E continuas tendo seus datasets populados como se estivesse conectado ao
banco diretamente.

Em 9 de março de 2016 18:30, Guimarães Faria Corcete DUTRA, Leandro <
l...@dutras.org> escreveu:

> 2016-03-09 17:38 GMT-03:00 Shander Lyrio :
> >
> > Em 9 de março de 2016 10:36, Flavio Henrique Araque Gurgel
> >  escreveu:
> >>>
> >> Desculpe, não havia JDBC na pergunta original do colega, ele usa Delphi.
> >> Não tenho parâmetros de comparação JDBC/libpq, mesmo se eu use ambos
> todos
> >> os dias.
> >
> > Legal, ele usa Delphi, mas você falou de REST certo?
>
> Não, foi alguém mais, o Gurgel só respondeu.  Leia as mensagens
> anteriores antes de cantar de galo.
>
>
> > ORM não faz parte do mundo dos bancos de dados
>
> Por isso mesmo está desacreditado.  Porque é uma solução porca de
> programadores que nunca entenderam modelos de dados.
>
>
> > ORM faz parte do mundo dos
> > aplicativos que utilizam banco de dados relacionais.
>
> Não, que usam bases de dados SQL.  Relacional de verdade nunca teria
> precisado de ORM.  Nem SQL, mas com relacional a ‘necessidade’ seria
> ainda mais obviamente absurda.
>
>
>
> > Se ORM fosse
> > desacreditada, então não teríamos 100% dos projetos utilizam ORM hoje
>
> Não temos, ainda bem.  Informe-se melhor.
>
>
> > Talvez você não saiba, mas qualquer ORM aceita consultas sql nativas do
> > banco de dados, não precisa ser utilizado a linguagem do ORM
>
> E aí ele se torna contraproducente, peso morto.
>
>
> > De qualquer forma, não estou aqui indicando REST e ORM para todo mundo,
> só
> > acho que não adianta ficar fazendo bulling sem conhecer as ferramentas.
>
> Posso te garantir que o Gurgel conhece-as, bem melhor que tu.
>
> Pesquise também SQL Alchemy.
>
>
> --
> 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
>
___
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 - OFF-TOPIC

[Shander Lyrio]

Em 9 de março de 2016 18:30, Guimarães Faria Corcete DUTRA, Leandro <
l...@dutras.org> escreveu:

>
> Não, foi alguém mais, o Gurgel só respondeu.  Leia as mensagens
> anteriores antes de cantar de galo.
>
>
​Exatamente, porque você não le as mensagens anteriores, não estou cantando
de galo, sequer inferindo, ele escreveu com todas as letras. e a oração me
parecia bastante completa.

> ORM não faz parte do mundo dos bancos de dados
>
> Por isso mesmo está desacreditado.  Porque é uma solução porca de
> programadores que nunca entenderam modelos de dados.
>
>
​Talvez esteja no seu mundinho particular. Todos os principais frameworks
full stack de desenvolvimento em praticamente todas as linguagens tem seu
ORM.​ A solução porca resolve muito bem o problema, sinto muito por você e
por sua opinião que não é compartilhada pelo resto da humanidade.



> > ORM faz parte do mundo dos
> > aplicativos que utilizam banco de dados relacionais.
>
> Não, que usam bases de dados SQL.  Relacional de verdade nunca teria
> precisado de ORM.  Nem SQL, mas com relacional a ‘necessidade’ seria
> ainda mais obviamente absurda.
>


​Leandro, há muitos anos nesta mesma lista eu ouço sempre você falando
desta mesma ladainha que é linda na teoria mas não se comprova na prática.​
Sinto muito por não ser iludido como você e por acreditar que o meio termo
é sempre a melhor saída. Não adianta vir com este assunto sem sentido para
discutir comigo, eu trabalho com banco de dados relacionais desde o finado
Sybase em 1998 e sei bem o que funciona e o que não funciona.



> > Se ORM fosse
> > desacreditada, então não teríamos 100% dos projetos utilizam ORM hoje
>
> Não temos, ainda bem.  Informe-se melhor.
>
>
​Hauahauahauah, técnica de discussão comigo?​ Estou muito bem informado meu
caro, mais de 25 anos trabalhando com desenvolvimento de softwares desde o
Xenix, mais de 12 anos que conheço você desta lista e sua chatice. Algumas
boas contribuições, é evidente, mas nada sem antes tentar inferiorizar o
interlocutor da pergunta sobre caixa alta ou baixa no nome do banco, e
argumentos sem sentido utilizando técnias de discussão para atrapalhar a
vida de quem acaba de chegar. Você é apenas um chato, um aprendiz de troll,
escrevendo coisas que não trazem nenhuma substância para a discussão para
se fazer de entendido. Vai me enxer o saco agora sobre conversa fora do
contexto da thread? O que você contribuiu sobre o assunto? Que tal me
informar sobre projetos bons, que sejam usados e atualizados, que utilizem
linguagens orientadas a objetos modernas e que não utilizam ORM. Que tal
contribuir com algo que eu não saiba.


> Talvez você não saiba, mas qualquer ORM aceita consultas sql nativas do
> > banco de dados, não precisa ser utilizado a linguagem do ORM
>
> E aí ele se torna contraproducente, peso morto.
>


​Não, é aí que ele brilha, torna o trabalho 99% do tempo fácil sem
influenciar na performance do banco de dados e quando por algum motivo
influencia, pode ser usado de forma a se adaptar ​ao banco de dados através
de uma sql nativa. Extremamente produtivo e nada de peso morto, excelente
ferramenta que certamente você nunca deve ter usado.


> > De qualquer forma, não estou aqui indicando REST e ORM para todo mundo,
> só
> > acho que não adianta ficar fazendo bulling sem conhecer as ferramentas.
>
> Posso te garantir que o Gurgel conhece-as, bem melhor que tu.
>
> Pesquise também SQL Alchemy.
>


​Você não pode garantir nada, eu trabalho com Python há mais de 10 anos e
SqlAlchemy há 7 anos desde sua versão 0.4. Sua opinião é baseada em
falácias pois você não escreve código. Pesquisar oque sobre SqlAlchemy?
você quer uma aula do que sobre SqlAlchemy? O que SqlAlchemy diverge de
qualquer coisa que eu tenha falado aqui?

Que fique claro que não estou desmerecendo o conhecimento do Gurgel, pois
este está mais do que provado não apenas nesta lista. Ao contrário de você,
ele sempre tratou qualquer membro com muita vontade de ajudar e humildade.
Pessoa que admiro e respeito sempre, apesar de não concordar com algumas
opiniões como o caso desta thread, algo absolutamente normal. A discussão
seguia rica e esperava que mais conhecimento fosse entregue a esta thread
até você aparecer.

Vai colocar algum conteúdo que tenha haver com o assunto ou vai ficar
apenas trollando?

Abraço,

--
Shander Lyrio
___
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

[Guimarães Faria Corcete DUTRA , Leandro]

2016-03-09 17:38 GMT-03:00 Shander Lyrio :
>
> Em 9 de março de 2016 10:36, Flavio Henrique Araque Gurgel
>  escreveu:
>>>
>> Desculpe, não havia JDBC na pergunta original do colega, ele usa Delphi.
>> Não tenho parâmetros de comparação JDBC/libpq, mesmo se eu use ambos todos
>> os dias.
>
> Legal, ele usa Delphi, mas você falou de REST certo?

Não, foi alguém mais, o Gurgel só respondeu.  Leia as mensagens
anteriores antes de cantar de galo.


> ORM não faz parte do mundo dos bancos de dados

Por isso mesmo está desacreditado.  Porque é uma solução porca de
programadores que nunca entenderam modelos de dados.


> ORM faz parte do mundo dos
> aplicativos que utilizam banco de dados relacionais.

Não, que usam bases de dados SQL.  Relacional de verdade nunca teria
precisado de ORM.  Nem SQL, mas com relacional a ‘necessidade’ seria
ainda mais obviamente absurda.



> Se ORM fosse
> desacreditada, então não teríamos 100% dos projetos utilizam ORM hoje

Não temos, ainda bem.  Informe-se melhor.


> Talvez você não saiba, mas qualquer ORM aceita consultas sql nativas do
> banco de dados, não precisa ser utilizado a linguagem do ORM

E aí ele se torna contraproducente, peso morto.


> De qualquer forma, não estou aqui indicando REST e ORM para todo mundo, só
> acho que não adianta ficar fazendo bulling sem conhecer as ferramentas.

Posso te garantir que o Gurgel conhece-as, bem melhor que tu.

Pesquise também SQL Alchemy.


-- 
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] VELOCIDADE DE ACESSO REMOTO AO POSTGRESQL

[Shander Lyrio]

Em 9 de março de 2016 10:36, Flavio Henrique Araque Gurgel  escreveu:

> Em 9 de março de 2016 09:32, Flavio Henrique Araque Gurgel
>> > escreveu:
>>
>>
>> Colocar um servidor Web para fazer uma camada REST sobre o protocolo
>> do PostgreSQL, só vai colocar MAIS UMA camada por cima. A libpq
>> continua lá.
>>
>>
>> ​Aqui não continua, uso jdbc type 4, não usamos libpq. O drive jdbc do
>> Postgres tem sido mais rápido do que acessar com a libpq em C++ em todos
>> os testes que fizemos. ​
>>
>
> Desculpe, não havia JDBC na pergunta original do colega, ele usa Delphi.
> Não tenho parâmetros de comparação JDBC/libpq, mesmo se eu use ambos todos
> os dias.
>
>
​Legal, ele usa Delphi, mas você falou de REST certo?​ Falou ainda de
servidor Web para a camada REST, logo você praticamente excluiu o Delphi
dai. Apesar de você conseguir fazer isto em Delphi, não é comum ver alguém
fazendo.


Foro na solução - técnicas para eliminar viagens de rede - são
>> inúmeras, citei algumas.
>>
>> ​Solicitações utilizando um serviço remoto que responde em algum
>> protocolo, HTTP no caso de REST também é uma técnica para eliminar
>> viagens de rede.​ Usar um ORM também é uma boa técnica para isto já que
>> você pode fazer dezenas de instruções Sql que somente irão ser enviadas
>> ao banco "flush" no momento do "commit".
>>
>
> Desculpe, ORM é uma entidade desacreditada no mundo dos bancos de dados e
> só tenho a discordar. Vide movimentos pelo jOOQ (mundo Java) e Pomm (mundo
> PHP).
> Passo meus dias a tirar consultas de um ORM "padrão de mercado"(Hibernate)
> e passando para SQL direto numa aplicação e resolvendo pelo menos um
> problema de desempenho por semana fazendo isso.
> E, por favor, explique-me como fazer uma transação complexa de banco de
> dados em REST.
>

​ORM não faz parte do mundo dos bancos de dados, ORM faz parte do mundo dos
aplicativos que utilizam banco de dados relacionais. Se ORM fosse
desacreditada, então não teríamos 100% dos projetos utilizam ORM hoje em
dia, já temos ORM até para Delphi. E aqui não importa se os programadores
sabem ou não SQL, ou se deveriam ou não saber SQL, importa que todos os
projetos hoje em dia utilizam ORM. Outra coisa, Hibernate não é sinônimo de
ORM, aqui por exemplo não usamos Hibernate porque ele não gera boas sql`s.
Talvez você não saiba, mas qualquer ORM aceita consultas sql nativas do
banco de dados, não precisa ser utilizado a linguagem do ORM, desta forma,
seus programadores só precisariam verificar se as Sql's geradas pelo seu
ORM; se percebessem alguma coisa anormal, escrever a consulta em sql
nativo. Em fim, ORM ajuda em 99% dos casos e no momento que ele é 1%
vagabundo, basta usar sql nativa, portanto não estão desacreditados, estão
na verdade sendo cada vez mais usados, tornando-se quase uma condição *sine
qua nom*.​

​Uma transação complexa pode ser feita normalmente em rest, basta que tudo
esteja emcapsulado em uma única chamada, e esta é exatamente a beleza da
coisa.​

​De ​qualquer forma, não estou aqui indicando REST e ORM para todo mundo,
só acho que não adianta ficar fazendo bulling sem conhecer as ferramentas.
Nada funciona 100% para tudo. Às vezes contornar um pequeno problema para
ter um grande ganho vale a pena. Ninguém deixa de usar carro só porque tem
que perder tempo comprando gasolina ou porque tem que fazer manutenção de
tempos em tempos, ou mesmo porque ele não voa quando temos um
engarrafamento.

​ps: Nem sabia da existência de JOOQ, muito menos Pomm​, mas olhando os
dois não vi nada de muito legal. Se eu já posso usar sql`s nativas num ORM
qualquer, porque eu perderia 99% do benefício só porque ele resolve 1% do
problema?


​Abraço,​

--
​Shander Lyrio​
___
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

[Flavio Henrique Araque Gurgel]

Em 9 de março de 2016 09:32, Flavio Henrique Araque Gurgel
> escreveu:


Colocar um servidor Web para fazer uma camada REST sobre o protocolo
do PostgreSQL, só vai colocar MAIS UMA camada por cima. A libpq
continua lá.


​Aqui não continua, uso jdbc type 4, não usamos libpq. O drive jdbc do
Postgres tem sido mais rápido do que acessar com a libpq em C++ em todos
os testes que fizemos. ​


Desculpe, não havia JDBC na pergunta original do colega, ele usa Delphi.
Não tenho parâmetros de comparação JDBC/libpq, mesmo se eu use ambos 
todos os dias.



REST não serve pra substituir uma conexão direta com um banco de dados.

​Ninguém disse isto pelo que me lembro. Temos um problema que é a
velocidade de acesso a dados em um banco PostgreSql remoto. Uma das
possíveis idéias (que não deveria ser ignorada simplesmente por não ser
a sua) é utilizar REST para fazer isto. REST pode ser a solução para a
"velocidade de acesso remoto" que é o título da pergunta e não para
"substituir uma conexão direta com banco de dados" como você está
dizendo. Estamos respondendo a pergunta, e não o que você acha que está
sendo perguntado.


Não foi minha intenção colocar nenhuma das respostas em detrimento de 
outras. Mas sim, mantenho minha opinião de que uma camada REST vai 
incluir mais problemas do que soluções. A opinião é minha e é meu dever 
colocá-la aqui.



1) Manter um pool de conexões, mesmo que 1:1, pode sim melhorar as
coisas por evitar o (baixo, mas importante quando o banco tá longe)
overhead de abrir e fechar conexões.


​Não é baixo. Talvez seja irrelevante se você tem poucos acessos, mas
não é baixo. Em um server que responde a um sistema em PHP que temos,
usar um pool de conexões reduziu o tempo de resposta em média de 25ms
linearmente em todas as requisições com acesso à dados. O banco estava
na própria máquina onde estava o sistema. Junte-se isto a uma média de
100 req/seg em horário de pico que temos sim uma grande diferença.


Foi exatamente o que falei, não entendi porque você escreveu isso.
O overhead é sim, muito baixo - mas pode se tornar importante se você 
tem alta latência (como eu disse) ou centenas de conexões/desconexões 
por segundo (como você disse)
Logo, estamos plenamente de acordo que um pool de conexões deve *sim* 
ajudar no cenário.



Extra: Comparar PHP com Delphi, libpq com REST, sua comparação aqui
= Flamewar besta.

​Acho que sou ingênuo. Não vi estas comparações aqui.​


Eram de outras respostas, talvez não as suas.


Foco no problema - latência de rede


​O problema não é este, isto é o que você acha que é. Mudar a pergunta
para inutilizar respostas de outros membros não é legal. De acordo com o
título, o problema é "velocidade de acesso remoto ao postgresql" e você
está apenas inferindo que isto se trata de latência de rede.​ Não se
está ignorando a latência de rede, claro que ela pode ser sim um dos
problemas, mas podem e certamente existem vários outros problemas que
podem influenciar, assim como existem várias técnicas para se contornar
cada um destes problemas.


Existem duas possibilidades, latência e taxa de transferência.
Eu respondi de acordo com minha experiência, tentando ajudar.
Assim, só de passagem, eu administro de um local central, servidores de 
bancos de dados em 3 continentes.
E, coloquei na minha resposta, as técnicas que uso - menos consultas, 
com mais dados por consulta = ganho expressivo.



Foro na solução - técnicas para eliminar viagens de rede - são
inúmeras, citei algumas.

​Solicitações utilizando um serviço remoto que responde em algum
protocolo, HTTP no caso de REST também é uma técnica para eliminar
viagens de rede.​ Usar um ORM também é uma boa técnica para isto já que
você pode fazer dezenas de instruções Sql que somente irão ser enviadas
ao banco "flush" no momento do "commit".


Desculpe, ORM é uma entidade desacreditada no mundo dos bancos de dados 
e só tenho a discordar. Vide movimentos pelo jOOQ (mundo Java) e Pomm 
(mundo PHP).
Passo meus dias a tirar consultas de um ORM "padrão de 
mercado"(Hibernate) e passando para SQL direto numa aplicação e 
resolvendo pelo menos um problema de desempenho por semana fazendo isso.
E, por favor, explique-me como fazer uma transação complexa de banco de 
dados em REST.



Vamos subir o nível desta lista?


​Simbora, começando por não alterar a pergunta​ para desvalorizar
respostas que não sejam a sua além de parar de inferir que todo munda
usa as ferramentas que você acha que elas usam.


Desculpe, não alterei a pergunta, coloquei minha experiência no assunto. 
pena que não foi tão bem vinda. Eu não queria incomodar ninguém.


Grande abraço,
Flavio.
___
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

[Shander Lyrio]

Em 9 de março de 2016 09:32, Flavio Henrique Araque Gurgel  escreveu:

>
> Colocar um servidor Web para fazer uma camada REST sobre o protocolo do
> PostgreSQL, só vai colocar MAIS UMA camada por cima. A libpq continua lá.
>
>
​Aqui não continua, uso jdbc type 4, não usamos libpq. O drive jdbc do
Postgres tem sido mais rápido do que acessar com a libpq em C++ em todos os
testes que fizemos. ​

REST não serve pra substituir uma conexão direta com um banco de dados.
>
>
​Ninguém disse isto pelo que me lembro. Temos um problema que é a
velocidade de acesso a dados em um banco PostgreSql remoto. Uma das
possíveis idéias (que não deveria ser ignorada simplesmente por não ser a
sua) é utilizar REST para fazer isto. REST pode ser a solução para a
"velocidade de acesso remoto" que é o título da pergunta e não para
"substituir uma conexão direta com banco de dados" como você está dizendo.
Estamos respondendo a pergunta, e não o que você acha que está sendo
perguntado.


> 1) Manter um pool de conexões, mesmo que 1:1, pode sim melhorar as coisas
> por evitar o (baixo, mas importante quando o banco tá longe) overhead de
> abrir e fechar conexões.
>
>
​Não é baixo. Talvez seja irrelevante se você tem poucos acessos, mas não é
baixo. Em um server que responde a um sistema em PHP que temos, usar um
pool de conexões reduziu o tempo de resposta em média de 25ms linearmente
em todas as requisições com acesso à dados. O banco estava na própria
máquina onde estava o sistema. Junte-se isto a uma média de 100 req/seg em
horário de pico que temos sim uma grande diferença.


> Extra: Comparar PHP com Delphi, libpq com REST, sua comparação aqui =
> Flamewar besta.
>
>
​Acho que sou ingênuo. Não vi estas comparações aqui.​


> Foco no problema - latência de rede
>

​O problema não é este, isto é o que você acha que é. Mudar a pergunta para
inutilizar respostas de outros membros não é legal. De acordo com o título,
o problema é "velocidade de acesso remoto ao postgresql" e você está apenas
inferindo que isto se trata de latência de rede.​ Não se está ignorando a
latência de rede, claro que ela pode ser sim um dos problemas, mas podem e
certamente existem vários outros problemas que podem influenciar, assim
como existem várias técnicas para se contornar cada um destes problemas.


Foro na solução - técnicas para eliminar viagens de rede - são inúmeras,
> citei algumas.
>
>
​Solicitações utilizando um serviço remoto que responde em algum protocolo,
HTTP no caso de REST também é uma técnica para eliminar viagens de rede.​
Usar um ORM também é uma boa técnica para isto já que você pode fazer
dezenas de instruções Sql que somente irão ser enviadas ao banco "flush" no
momento do "commit".


> Vamos subir o nível desta lista?
>
>
​Simbora, começando por não alterar a pergunta​ para desvalorizar respostas
que não sejam a sua além de parar de inferir que todo munda usa as
ferramentas que você acha que elas usam.

--
​Shander Lyrio​
___
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

[Flavio Henrique Araque Gurgel]

Em 8 de março de 2016 10:27, Fabrízio de Royes Mello
> escreveu:


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.


​Mesmo levando em consideração que toda a transferência de dados por
REST será "gzipada"​.

​Pergunto isto, pois tenho um sistema assim(não usando Delphi), a
aplicação que roda no servidor tem um pool de conexões com o PostgreSql.
Eu gostaria de ver um pool de conexões remotas para ter uma idéia ​do
tipo de coisa linda que seria, principalmente um pool de conexões para
aplicações desktop.

Já foi dito acima que existe muitas coisas que influenciam na velocidade
de uma comunicação remota, payload certamente não me parece ser a mais
relevante.


Nossa gente, como está faltando contexto, técnica e está sobrando flame 
nesta discussão!


Outro colega colocou que com REST dá pra usar pool de conexões e com a 
libpq não dá, de onde veio isso???

O pgbouncer é feito para a libpq.

Colocar um servidor Web para fazer uma camada REST sobre o protocolo do 
PostgreSQL, só vai colocar MAIS UMA camada por cima. A libpq continua lá.


Sim, REST vai adicionar *um monte* de coisas: overhead do http + 
json/xml (ou o que você quiser, REST não limita a isso), perda da 
capacidade de fazer transações atômicas, entre outras coisas. Vocês 
terão de usar prepared transactions, por exemplo, que é outra carga.


REST não serve pra substituir uma conexão direta com um banco de dados.

Se vocês estão tendo problemas de lentidão, difícilmente é a taxa o 
problema - o que normalmente causa isso é latência.


A libpq é bastante enxuta.

Se o servidor de banco de dados está longe, e vocês usam ORM, por 
exemplo, ou se uma página faz loops com pequenos SELECT, ou se uma 
aplicação que abstrai dados faz assim (não sei como os conectores Delphi 
fazem), aí é a causa do problema.


1) Manter um pool de conexões, mesmo que 1:1, pode sim melhorar as 
coisas por evitar o (baixo, mas importante quando o banco tá longe) 
overhead de abrir e fechar conexões.


2) Evite pequenos SELECT pra montar uma página/tela de resposta - 
prefiram um grande SELECT que, mesmo que seja mais pesado pra executar 
no servidor de dados, a resposta não precisará de várias idas e vindas 
via Internet.


3) Testem a latência - PING mesmo. A taxa, provavelmente, não foi saturada.

4) Evitem a todo custo usar ORM/abstração de objetos nesse contexto.

Extra: Comparar PHP com Delphi, libpq com REST, sua comparação aqui = 
Flamewar besta.


Foco no problema - latência de rede
Foro na solução - técnicas para eliminar viagens de rede - são inúmeras, 
citei algumas.


Vamos subir o nível desta lista?

[]s
Flavio Gurgel
___
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

[Shander Lyrio]

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

>
> 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.
>
>
​Mesmo levando em consideração que toda a transferência de dados por REST
será "gzipada"​.

​Pergunto isto, pois tenho um sistema assim(não usando Delphi), a aplicação
que roda no servidor tem um pool de conexões com o PostgreSql. Eu gostaria
de ver um pool de conexões remotas para ter uma idéia ​do tipo de coisa
linda que seria, principalmente um pool de conexões para aplicações desktop.

Já foi dito acima que existe muitas coisas que influenciam na velocidade de
uma comunicação remota, payload certamente não me parece ser a mais
relevante.

--
​Shander Lyrio​
___
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

[Ivo Sestren Junior]

Tem que considerar também que via rede, qualquer request o tempo para
receber é em torno de 1ms.
Enquanto na internet varia muito, normalmente em torno de 50ms, podendo
chegar a mais de 1s.
Só para o servidor receber a requisição da conexão/consulta.
O que só nisto provavelmente faz chegar aos 2s que você esta tendo no uso
via internet.

Em 8 de março de 2016 21:24, itamar  escreveu:

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

[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

[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

[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

[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

[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

[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

[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] VELOCIDADE DE ACESSO REMOTO AO POSTGRESQL

[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] VELOCIDADE DE ACESSO REMOTO AO POSTGRESQL

[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] VELOCIDADE DE ACESSO REMOTO AO POSTGRESQL

[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] VELOCIDADE DE ACESSO REMOTO AO POSTGRESQL

[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

[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

[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] VELOCIDADE DE ACESSO REMOTO AO POSTGRESQL

[Guimarães Faria Corcete DUTRA , Leandro]

2016-03-07 9:02 GMT-03:00  :
>
> Nos meus testes comparando MySQL com Postgres em acesso remoto a mesma
> estrutura de dados e indices o MySQL fica um pouco mais rapido, mas nada que
> justifique uma migração, eu ainda prefiro o Postgres pela robustes.

Esses testes não suportam uma generalização de que o MySQL seja mais
rápido que o PostgreSQL em acesso remoto.  Há muitas variáveis a
considerar.  Mesmo para a situação específica que você testou,
precisaria comparar a diferença entre o mesmo trabalho em acesso
remoto ou local.


> Olha, eu uso Delphi a muitos anos e gosto muito, mas quando se fala em
> acesso a base de dados remoto pra trabalhos pesados, aiii... que desespero,
> corro logo pra uma linguagem mais apropriada. no meu caso PHP.

Creio que seria importante diferenciar a linguagem (Object Pascal) do
ambiente de desenvolvimento, o Delphi.  A linguagem não morre; o
Lazarus está aí para isso.  Mas o futuro do Delphi é cada dia mais
irrelevante.


-- 
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] VELOCIDADE DE ACESSO REMOTO AO POSTGRESQL

[Vinicius Santos]

O problema não é com o componente.
Mesmo usando pgAdmin ou psql a lentidão continua. Você está usando uma
solução cliente-servidor pela internet, você vai precisar de um link
dedicado pra melhorar isso, ou:

1) Utilizar 3 camadas, em Delphi(DataSnap), para que o banco de dados fique
do lado do servidor de aplicações.
2) Utilizar Terminal Service. Deixe o aplicativo do lado do banco de dados
também.
3) Utilizar um link dedicado. Já utilizamos um link dedicado de 10MB, na
mesma situação que a sua. Porém o link era direto com o Data Center(Alog).
Usando tracert dava pra ver que não existia muitos saltos até o destino e
funcionava bem.


Em 7 de março de 2016 09:02, <siste...@mvsoftware.com.br> escreveu:

> Na internet do brazil até o MySQL que é muito bom pra acesso remoto fica
> ruim.
>
> Nos meus testes comparando MySQL com Postgres em acesso remoto a mesma
> estrutura de dados e indices o MySQL fica um pouco mais rapido, mas nada
> que justifique uma migração, eu ainda prefiro o Postgres pela robustes.
>
> Pra acessar uma base remotamente “pelo menos no brazil” ou você usa uma
> super VPN ou uma super fibra, acessar via IP normal é suicidio, a menos que
> trabalhe com poucos dados ai vc pode trabalhar com json ou webservices já
> que o acesso não será direto.
>
> Em resumo, o problema não está 100% no banco, mas nos serviços oferecidos
> no brazil, já que eles garantem (por lei/contrato, ridiculo) no máximo 10%
> do que você contratar (internet normal).
>
> Olha, eu uso Delphi a muitos anos e gosto muito, mas quando se fala em
> acesso a base de dados remoto pra trabalhos pesados, aiii... que desespero,
> corro logo pra uma linguagem mais apropriada. no meu caso PHP.
>
> Olha uma opção que caiu em desuso é o CGI que você poderia trabalhar com
> Delphi numa boa, estou dizendo isso porque normalmente quando tentamos
> trazer o delphi pra acesso remoto é a segurança do código em servidores
> alheios que estão em jogo, pois seria muito mais rápido um php da vida.
>
> E quanto a dizer que o delphi está morto, acho muito estranho, mal ouço
> falar em VB, mas ele continua vivo com o visual studio, e o delphi no agora
> Delphi Seattle.
> Acho que a sensação de que o Delphi está morto é porque não ouvimos falar
> nele quando falamos em aplicações mobile ou web, mas o delphi tem IDE pra
> isso.
> Agora quando se fala em ERP pra pequenas e médias empresas, na minha
> opinião o Delphi deve ser o mais usado, pessoal não me entendam mal, é só o
> que acho heim , rsrsr
>
>
> Marcelo Silva
>
>
>
> *From:* Reijanio Nunes Ribeiro <rnribe...@gmail.com>
> *Sent:* Sunday, March 6, 2016 3:41 PM
> *To:* Comunidade PostgreSQL Brasileira
> <pgbr-geral@listas.postgresql.org.br>
> *Subject:* Re: [pgbr-geral] VELOCIDADE DE ACESSO REMOTO AO POSTGRESQL
>
>
> Afirmaçao ridícula
> Em 05/03/2016 18:32, "Itamar Reis Peixoto" <ita...@ispbrasil.com.br>
> escreveu:
>
>>
>>
>> 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.
>>
>> ___
>> 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 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

[sistemas]

Na internet do brazil até o MySQL que é muito bom pra acesso remoto fica ruim.

Nos meus testes comparando MySQL com Postgres em acesso remoto a mesma 
estrutura de dados e indices o MySQL fica um pouco mais rapido, mas nada que 
justifique uma migração, eu ainda prefiro o Postgres pela robustes.

Pra acessar uma base remotamente “pelo menos no brazil” ou você usa uma super 
VPN ou uma super fibra, acessar via IP normal é suicidio, a menos que trabalhe 
com poucos dados ai vc pode trabalhar com json ou webservices já que o acesso 
não será direto.

Em resumo, o problema não está 100% no banco, mas nos serviços oferecidos no 
brazil, já que eles garantem (por lei/contrato, ridiculo) no máximo 10% do que 
você contratar (internet normal).

Olha, eu uso Delphi a muitos anos e gosto muito, mas quando se fala em acesso a 
base de dados remoto pra trabalhos pesados, aiii... que desespero, corro logo 
pra uma linguagem mais apropriada. no meu caso PHP.

Olha uma opção que caiu em desuso é o CGI que você poderia trabalhar com Delphi 
numa boa, estou dizendo isso porque normalmente quando tentamos trazer o delphi 
pra acesso remoto é a segurança do código em servidores alheios que estão em 
jogo, pois seria muito mais rápido um php da vida.

E quanto a dizer que o delphi está morto, acho muito estranho, mal ouço falar 
em VB, mas ele continua vivo com o visual studio, e o delphi no agora Delphi 
Seattle.
Acho que a sensação de que o Delphi está morto é porque não ouvimos falar nele 
quando falamos em aplicações mobile ou web, mas o delphi tem IDE pra isso.
Agora quando se fala em ERP pra pequenas e médias empresas, na minha opinião o 
Delphi deve ser o mais usado, pessoal não me entendam mal, é só o que acho heim 
, rsrsr


Marcelo Silva



From: Reijanio Nunes Ribeiro 
Sent: Sunday, March 6, 2016 3:41 PM
To: Comunidade PostgreSQL Brasileira 
Subject: Re: [pgbr-geral] VELOCIDADE DE ACESSO REMOTO AO POSTGRESQL

Afirmaçao ridícula 

Em 05/03/2016 18:32, "Itamar Reis Peixoto" <ita...@ispbrasil.com.br> escreveu:



  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.

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

[Reijanio Nunes Ribeiro]

Afirmaçao ridícula
Em 05/03/2016 18:32, "Itamar Reis Peixoto" 
escreveu:

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

[Izaque Maciel]

Em 5 de março de 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)
>
> hostall all 177.42.58.148/32md5
>
> - 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á!
>
>
> --
>
> *---  Ali do Amaral Pedrozo *
> *  ali@gmail.com *
>
>
> *---*
>
> ___
> pgbr-geral mailing list
> pgbr-geral@listas.postgresql.org.br
> https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
>


Firedac é bem rápido. Utilize select campo1, campo2, ... from compra, e se
como mencionado por alguns colegas, se tiver a opção de utilizar JSON, o
delphi suporta JSON e BSON (Binary JSON), através do Firedac.
___
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

[Gerdan Rezende dos Santos]

Ta conectando por ip ou por dns??? Já vi coisa identica demorando pra
resolver dns...

Em sábado, 5 de março de 2016, lu moraes santos 
escreveu:

> Ola amigo, delphi não é uma linguagem morta não, o Rest json você consegue
> trabalhar no delphi usando datasnap. Tranquilo. Delphi você desenvolve pra
> Windows, Android, Apple nativamente.  O acesso de minha aplicação em delphi
> com Postgres é extremamente rápido. Peço pro amigo fazer um teste usando o
> unidac.
> Em 5 de mar de 2016 6:32 PM, "Itamar Reis Peixoto" <
> ita...@ispbrasil.com.br
> > escreveu:
>
>>
>>
>> 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.
>>
>> ___
>> pgbr-geral mailing list
>> pgbr-geral@listas.postgresql.org.br
>> 
>> https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
>
>

-- 
*Gerdan Rezende dos Santos *
*Po*stgreSQL & EnterpriseDB Specialist, Support, Training & Services
+55 (61) 9645-1525
___
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

[lu moraes santos]

Ola amigo, delphi não é uma linguagem morta não, o Rest json você consegue
trabalhar no delphi usando datasnap. Tranquilo. Delphi você desenvolve pra
Windows, Android, Apple nativamente.  O acesso de minha aplicação em delphi
com Postgres é extremamente rápido. Peço pro amigo fazer um teste usando o
unidac.
Em 5 de mar de 2016 6:32 PM, "Itamar Reis Peixoto" 
escreveu:

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

[Itamar Reis Peixoto]

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.

___
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

[lu moraes santos]

O Firedac é muito rápido para acesso, atualmente uso o zeos, faz conexão
nativa,  tente usar o unidac ele é o mais rápido.
Em 5 de mar de 2016 5:28 PM, "Fabrízio de Royes Mello" <
fabri...@timbira.com.br> escreveu:

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

[Fabrízio de Royes Mello]

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?

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

[Itamar Reis Peixoto]

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.

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