[pgbr-geral] ERROR: canceling statement

2016-02-10 Por tôpico drum.lu...@gmail.com 
Olá a todos


O erro a baixo pode ser devido a Query estar "errada"? Ou seria um problema
relacionado a recursos da máquina/DB?

Obrigado.



PostgreSQL 9.2

ERROR:  canceling statement due to statement timeout
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Algoritmos de Junções X SSD

2016-02-10 Por tôpico Neto pr 
Em 10 de fevereiro de 2016 07:32, Flavio Henrique Araque Gurgel <
fha...@gmail.com> escreveu:

> Pessoal
>>
>> O algoritmo MERGE-JOIN ou HASH-JOIN normalmente é escolhido pelo
>> Otimizador ao inves do NESTED-LOOP, devido a ter melhor desempenho.
>>
>
> Não, ele é escolhido quando tem um custo mais baixo.
> Ok, isso mesmo que eu queria  dizer
>


> No entanto, se considerarmos a utilização de discos SSDs, que tem
>> velocidade de leitura mais de 100 vezes mais rápida que um HDD o
>> algoritmo NESTED-LOOP pode ser uma melhor opção, devido a trabalhar
>> somente com leituras. Outro fato é que o MERGE-JOIN e HASH-JOIN
>>
>
> Se considerarmos que o custo de leitura aleatória é mais baixo, um nested
> loop *pode* ser menos custoso em relação aos outros métodos de acesso.
>
> Discos SSD não são "100x mais rápidos" que discos rotativos. Isso depende
> muito da arquitetura de todo o sistema de armazenamento.
>
> Aqui eu falei que os SSDs são 100 vezes mais rápidos, mas somente para
leitura
deixo aqui uma referencia, de pesquisadores da HP que fizeram um estudo, já
antigo...
http://www.cs.cmu.edu/~damon2007/pdf/graefe07fiveminrule.pdf
Já vi artigos atuais em que os SSDs atuais chegam a ser 1000 vezes mais
rápidos Veja na pagina 2  do artigo que o custo de leitura de um SSD é
0,16 ms enquanto que de um HD é 12 ms, ou seja 75 vezes mais rápido.


> O que é mais interessante nos SSDs é que o "custo"  de leitura aleatória
> (randômica) é próximo, às vezes igual, ao "custo" de leitura sequencial.
>
> necessitam de bastante escrita, quando os dados não cabem na RAM, e se
>>
>
> Não há escrita em SELECT. Você está falando de temporários? Ajustar o
> work_mem para a consulta é uma alternativa válida em muitos casos, mesmo
> quando se tem SSD, que em alguns casos é péssimo em escrita.
>
> Estou falando de escrita, que são utilizadas na Junção para armazenar
resultados intermediários..


> considerarmos o maior preço por gigabyte de um SSDs, isso também deve
>>
>
> O custo que estou falando não é preço (apenas pra ficar claro).


Sim estou falando de dinheiro...

>
>
> ser considerado. Estou considerando ambientes exclusivos com discos SSDs.
>>
>> Alguém sabe se o PostgreSQL consegue identificar se o armazenamento está
>> sendo em um SSD para poder escolher melhor o algoritmo de Junção ?
>>
>
> Você precisa especificar o "custo de fazer leitura em disco". Para isso,
> você precisa ajustar os parâmetros random_page_cost e seq_page_cost do seu
> servidor de banco de dados.
>
> Muitos administradores tem colocado 1 como random_page_cost quando
> trabalha com SSDs, ou seja, assume-se que a leitura aleatória tem o mesmo
> "custo" que a leitura sequencial.
>

Excelente opção.

>
> No seu caso, você precisa testar. Abra uma sessão psql, altere os valores
> nesta sessão com SET, e teste suas consultas.
>
> Como os SSD tem performance ruim em escrita, acredito que vou tentar
implementar um ambiente hibrido, deixando os HDD para os arquivos
write-intensive (temp, logs) assim deixaria SSD somente para tabelas que
tenham bastante leitura... vale explicar para quem não tenha experiencia
com SSDs que a escrita não tem boa performance,  devido a não possibilidade
de sobrescrever ou atualizar dados. Ao invés disso, é realizado o processo
conhecido como *erase-before-write* onde um bloco inteiro deve ser apagado
e depois os novos dados podem ser escritos nas páginas do bloco, isso
significa que todas as outras páginas do bloco (que nao precisariam ser
alteradas), precisam ser lidas e, em seguida, escritas novamente. Em um SSD
um dado só pode ser escrito em um bloco vazio, por isso o processo de
erase-before-write.

Alguem teria uma sugestão de quais seguimentos de arquivos deixaria no SSDs
e quais  nos HDs ?
qualquer ajuda sera bem vinda.

[]`s Neto




> []s
> Flavio Gurgel
> ___
> 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] Algoritmos de Junções X SSD

2016-02-10 Por tôpico Flavio Henrique Araque Gurgel 

Pessoal

O algoritmo MERGE-JOIN ou HASH-JOIN normalmente é escolhido pelo
Otimizador ao inves do NESTED-LOOP, devido a ter melhor desempenho.


Não, ele é escolhido quando tem um custo mais baixo.


No entanto, se considerarmos a utilização de discos SSDs, que tem
velocidade de leitura mais de 100 vezes mais rápida que um HDD o
algoritmo NESTED-LOOP pode ser uma melhor opção, devido a trabalhar
somente com leituras. Outro fato é que o MERGE-JOIN e HASH-JOIN


Se considerarmos que o custo de leitura aleatória é mais baixo, um 
nested loop *pode* ser menos custoso em relação aos outros métodos de 
acesso.


Discos SSD não são "100x mais rápidos" que discos rotativos. Isso 
depende muito da arquitetura de todo o sistema de armazenamento.


O que é mais interessante nos SSDs é que o "custo"  de leitura aleatória 
(randômica) é próximo, às vezes igual, ao "custo" de leitura sequencial.



necessitam de bastante escrita, quando os dados não cabem na RAM, e se


Não há escrita em SELECT. Você está falando de temporários? Ajustar o 
work_mem para a consulta é uma alternativa válida em muitos casos, mesmo 
quando se tem SSD, que em alguns casos é péssimo em escrita.



considerarmos o maior preço por gigabyte de um SSDs, isso também deve


O custo que estou falando não é preço (apenas pra ficar claro).


ser considerado. Estou considerando ambientes exclusivos com discos SSDs.

Alguém sabe se o PostgreSQL consegue identificar se o armazenamento está
sendo em um SSD para poder escolher melhor o algoritmo de Junção ?


Você precisa especificar o "custo de fazer leitura em disco". Para isso, 
você precisa ajustar os parâmetros random_page_cost e seq_page_cost do 
seu servidor de banco de dados.


Muitos administradores tem colocado 1 como random_page_cost quando 
trabalha com SSDs, ou seja, assume-se que a leitura aleatória tem o 
mesmo "custo" que a leitura sequencial.


No seu caso, você precisa testar. Abra uma sessão psql, altere os 
valores nesta sessão com SET, e teste suas consultas.


[]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] Inteligência do postgresql ao fazer update

2016-02-10 Por tôpico Flavio Henrique Araque Gurgel 

Em 07/02/16, Saraiva Silva escreveu:

Pois é, meu interesse é porque eu tenho funções que fazem inserções e
updates. Como não é possível saber quais colunas o usuário irá atualizar,
então minha função de atualização tem parâmetros para todas as colunas. Mas
em uma tabela com 15 colunas, e o usuário alterar apenas uma coluna de um
registro, a função vai desperdiçar recursos. Pois ela irá atualizar todas
as outras colunas com dados repetidos.
O desafio é atualizar somente as colunas que realmente foram alteradas.
Como exemplo uma função que faz update em uma tabela de CEPs:

http://paste.ubuntu.com/14962205/

Como fazer a função atualizar somente as colunas alteradas?




Creio que você deveria dar uma estudada no modelo MVCC utilizado pelo
PostgreSQL.
http://www.postgresql.org/docs/current/interactive/mvcc.html
A cada updade uma nova versão do registro é gerada, ou seja, o
possível desperdício de recursos é mínimo frente a reescrever todo o
registro.


Queria apenas complementar a informação do Osvaldo, há sim dois impactos 
que não são negligenciáveis neste caso.


Com relação à escrita nas tabelas e MVCC, existe uma exceção a essa 
regra da nova tupla. para colunas que ultrapassam o mínimo previsto para 
que os dados caiam numa tabela TOAST (a partir de 2kiB na compilação 
padrão). Numa coluna desse tipo, em ambos os casos, se o valor dentro do 
UPDATE for o mesmo, ou se a coluna não for listada no comando, a tabela 
TOAST permanece inalterada.


O maior impacto que vejo para desempenho, a partir da versão 9.4, as 
porções não modificadas de um UPDATE não são escritos no WAL:

http://www.postgresql.org/docs/9.4/static/release-9-4.html
Isso pode reduzir *muito* a quantidade de escrita e de dados a guardar e 
replicar para casos de updates em massa.


Uma solução para o colega da pergunta original é de fazer várias tabelas 
com menos colunas. Neste caso, a função vai fazer UPDATE somente nas 
tabelas que tiveram colunas alteradas por exemplo. Claro que isso tem um 
custo para fazer junções depois, mas aí cada caso precisa ser analisado.


[]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] Erro "$ libdir / _int":

2016-02-10 Por tôpico Thiago H. Barreto 
Consegui resolver o problema.

Estava faltando instalar alguns componentes no Postgresql.

Executei o comando: postgresql-contrib-9.0

E deu certo.

Obrigado.

2016-02-10 1:36 GMT-02:00 Osvaldo Kussama :

> Em 09/02/16, Thiago H. Barreto escreveu:
> > Boa tarde Galera.
> >
> > Estou precisando da ajuda de vocês.
> > Tive que mudar um servidor que esta com problemas e quando acesso a
> > aplicação dá o seguinte erro.. "não pôde acessar arquivo "$libdir/_int":
> > Arquivo ou diretório não encontrado."
> >
> > Eu encontrei a seguinte explicação no google
> >
> > "Se você receber o erro ERRO: não foi possível acessar o arquivo "$
> libdir
> > / _int": Nenhum tal lima ou diretório , o que significa que os
> *intArray* e
> > *intagg* extensões precisam ser instalados no PostgreSQL."
> >
> > Alguem sabe como criar estas extensões no Ubuntu? Estou utilizando a
> versão
> > 14.04.
> >
>
>
> Veja:
> CREATE EXTENSION em:
> http://www.postgresql.org/docs/current/interactive/contrib.html
> e
> http://www.postgresql.org/docs/current/interactive/sql-createextension.html
>
> além de:
> http://www.postgresql.org/docs/current/interactive/intagg.html
> http://www.postgresql.org/docs/current/interactive/intarray.html
>
> Osvaldo
> ___
> pgbr-geral mailing list
> pgbr-geral@listas.postgresql.org.br
> https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral




-- 
Thiago H. Barreto
Sed Contabilidade S/S Ltda
(34) - 3662-1124
thi...@sedcontabilidade.com.br







*Lembre-se de que ao evitar o desperdício, além de economizar dinheiro com
papel e tinta, você também ajuda o nosso planeta. Bom para seu bolso,
melhor para o mundo!*
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Inteligência do postgresql ao fazer update

2016-02-10 Por tôpico Guimarães Faria Corcete DUTRA , Leandro 
2016-02-10 9:26 GMT-02:00 Flavio Henrique Araque Gurgel :
> Uma solução para o colega da pergunta original é de fazer várias tabelas com
> menos colunas. Neste caso, a função vai fazer UPDATE somente nas tabelas que
> tiveram colunas alteradas por exemplo. Claro que isso tem um custo para
> fazer junções depois, mas aí cada caso precisa ser analisado.

Incidentalmente, esse é um dos benefícios da normalização.  Também
ajuda a diminuir disputa por recursos (E/S, travamento de objetos), e
torna o modelo e sua operação mais fácil de compreender, além de
revelar muito sobre tanto dados quanto aplicações.  Geralmente
eventuais perdas com junções são mais que compensadas pelos
benefícios.


-- 
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] ERROR: canceling statement

2016-02-10 Por tôpico drum.lu...@gmail.com 
2016-02-11 12:20 GMT+13:00 Rafael Bernard Rodrigues Araujo <
rafael.ara...@endel.com.br>:

> oi, lucas.
>
> 2016-02-10 20:27 GMT-02:00 drum.lu...@gmail.com :
>
>> O erro a baixo pode ser devido a Query estar "errada"? Ou seria um
>> problema relacionado a recursos da máquina/DB?
>>
>> ERROR:  canceling statement due to statement timeout
>>
>
> pode ser uma consulta que esteja levando muito tempo ou pode ser o recurso
> da máquina que não consegue dar o resultado no tempo configurado.
>
> a configuração statement_timeout do postgresql.conf é o que define o tempo
> máximo que a consulta ocupará na conexão sem um resultado. é preciso
> verificar se isso não é gerado por uma consulta em particular ou se é em
> algum período de alto acesso que acaba deixando o servidor mais ocupado e
> demorando mais a responder às consultas.
>
>
>
Olá. Certo.

o statement_timeout estando 0 - Significa que ele irá utilizar as confs dos
usuários, certo?
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] ERROR: canceling statement

2016-02-10 Por tôpico Rafael Bernard Rodrigues Araujo 
oi, lucas.

2016-02-10 20:27 GMT-02:00 drum.lu...@gmail.com :

> O erro a baixo pode ser devido a Query estar "errada"? Ou seria um
> problema relacionado a recursos da máquina/DB?
>
> ERROR:  canceling statement due to statement timeout
>

pode ser uma consulta que esteja levando muito tempo ou pode ser o recurso
da máquina que não consegue dar o resultado no tempo configurado.

a configuração statement_timeout do postgresql.conf é o que define o tempo
máximo que a consulta ocupará na conexão sem um resultado. é preciso
verificar se isso não é gerado por uma consulta em particular ou se é em
algum período de alto acesso que acaba deixando o servidor mais ocupado e
demorando mais a responder às consultas.

abraço,
rafael
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] ERROR: canceling statement

2016-02-10 Por tôpico Dickson S. Guedes 
Em 10 de fevereiro de 2016 21:35, drum.lu...@gmail.com
 escreveu:
> o statement_timeout estando 0 - Significa que ele irá utilizar as confs dos
> usuários, certo?

Da documentação [1]:

---
statement_timeout (integer)

Abort any statement that takes over the specified number of
milliseconds, starting from the time the command arrives at
the server from the client. If log_min_error_statement is set
to ERROR or lower, the statement that timed out will also be
logged. A value of zero (the default) turns this off.

Setting statement_timeout in postgresql.conf is not
recommended because it affects all sessions.
---

Logo, se está 0 (zero) ele vai utilizar a conf da sessão do
cliente, ou seja, o usuário está fazendo isto intencionalmente
(via SET ... ) ou se você usa um pool de conexão ele pode
estar configurando isto no momento do início da sessão.

Algumas ferramentas de monitoramento definem esta variavel
para evitar que determinadas consultas rodem indefinidamente.

[1] http://www.postgresql.org/docs/9.2/static/runtime-config-client.html
-- 
Dickson S. Guedes
mail/xmpp: gue...@guedesoft.net - skype: guediz
http://github.com/guedes - http://guedesoft.net
http://www.postgresql.org.br
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral