Re: [pgbr-geral] Diversão com restrições

2016-09-08 Por tôpico Tiago José Adami 
Em 8 de setembro de 2016 17:17, Guimarães Faria Corcete DUTRA, Leandro
 escreveu:
> 2016-09-08 17:15 GMT-03:00 Fabrízio de Royes Mello :
>> Um índice parcial é criado para agir em uma
>> porção da tabela de acordo com o predicado definido (aka WHERE), então
>> você pode criar um índice regular ou um "unique" que irá respeitar as
>> tuplas envolvidas na porção definida pelo mesmo.
>
> Obrigado!  Mas acho que ainda merece uma explicação ainda mais clara
> para leigos.

Acontece muito em modelos onde há uma entidade, digamos, PESSOA, que
possui vários, digamos, ENDERECO, mas somente 1 ENDERECO pode ser
marcado como principal para cada PESSOA.

Normalmente recorre-se à triggers para fazer essa validação em banco
(eu, troglodita, faria isso), tendo que fazer um SELECT FOR UPDATE
verificando se já existe um principal para permitir a alteração, o que
foi solucionado simplesmente com um índice único parcial.

... nunca pensei nisso, diga-se de passagem.


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

Re: [pgbr-geral] Diversão com restrições

2016-09-08 Por tôpico Guimarães Faria Corcete DUTRA , Leandro 
2016-09-08 17:15 GMT-03:00 Fabrízio de Royes Mello :
> On 08-09-2016 16:55, Guimarães Faria Corcete DUTRA, Leandro wrote:
>> http://www.anserinae.net/fun-with-sql-constraints.html
>>
>> Ponto para quem explicar sucintamente em bom português.
>
> Qual a dúvida meu guri?

Nenhuma, só ‘tarefa de casa’ mesmo.  Preguiça de traduzir e explicar,
deixei para ti!  ;-)


> Um índice parcial é criado para agir em uma
> porção da tabela de acordo com o predicado definido (aka WHERE), então
> você pode criar um índice regular ou um "unique" que irá respeitar as
> tuplas envolvidas na porção definida pelo mesmo.

Obrigado!  Mas acho que ainda merece uma explicação ainda mais clara
para leigos.


-- 
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] Diversão com restrições

2016-09-08 Por tôpico Fabrízio de Royes Mello 
On 08-09-2016 16:55, Guimarães Faria Corcete DUTRA, Leandro wrote:
> http://www.anserinae.net/fun-with-sql-constraints.html
> 
> Ponto para quem explicar sucintamente em bom português.
> 

Qual a dúvida meu guri? Um índice parcial é criado para agir em uma
porção da tabela de acordo com o predicado definido (aka WHERE), então
você pode criar um índice regular ou um "unique" que irá respeitar as
tuplas envolvidas na porção definida pelo mesmo.

-- 
   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] Diversão com restrições

2016-09-08 Por tôpico Rafael Fialho 
2016-09-08 16:55 GMT-03:00 Guimarães Faria Corcete DUTRA, Leandro <
l...@dutras.org>:

> http://www.anserinae.net/fun-with-sql-constraints.html
>
> Ponto para quem explicar sucintamente em bom português.


Basicamente está demostrando o recurso "where" em uma unique constraint,
ou, no caso, um índice parcial.
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Lentidão no Postgres 9.5

2016-09-08 Por tôpico Fabrízio de Royes Mello 
On 08-09-2016 09:43, Irineu Raymundo wrote:
> Bom dia pessoal,
> 
> Estou com um problema de lentidão numa rotina, se alguém puder me dar
> uma luz do que eu poderia investigar fico imensamente agradecido.
> 
> O banco é : "PostgreSQL 9.5.4 on x86_64-pc-linux-gnu, compiled by gcc
> (Ubuntu 5.4.0-6ubuntu1~16.04.2) 5.4.0 20160609, 64-bit"
> 
> A trava aparentemente de forma aleatória, executa 2 dias normalmente e
> parece que do nada trava na última função e fica mais de 4 horas sendo
> obrigado a derrubar.
> 
> Conferi quando trava e não tem nenhuma outra instrução que poderia faz
> um lock nas tabelas.
> 
> Basicamente ela cria tabelas temporárias, faz os cálculos necessários e
> escreve numa tabela não logada(UNLOGGED) para poder imprimir o relatório
> via ODBC.
> Essa tabela fica com mais ou menos 2 milhões de registros, e tem uns 11
> índices.
> 
> Segue abaixo a rotina:
> 
> TRUNCATE senda.ind_03_03_04_01_lev CASCADE;
> TRUNCATE senda.ind_03_03_04_01_01_lev CASCADE;
> TRUNCATE senda.ind_03_03_04_01_01_a1_lev;
> REINDEX TABLE senda.ind_03_03_04_01_lev;

Porque o REINDEX em uma tabela que vc recém efetuou um TRUNCATE? O
TRUNCATE recria todos datafiles envolvidos (heap e btree).


> VACUUM FULL ANALYZE senda.ind_03_03_04_01_01_lev;
> VACUUM FULL ANALYZE senda.ind_03_03_04_01_01_a1_lev;
> VACUUM FULL ANALYZE senda.ind_03_03_04_01_lev;
> VACUUM FULL ANALYZE senda.ind_03_03_03_02_oc;

Aqui vc efetua um VACUUM FULL novamente e talvez sem necessidade,
principalmente pelo fato da "senda.ind_03_03_04_01_lev" ter sido
truncada anteriormente. Será que as demais tabelas não são truncadas
junto com as anteriores devido ao "CASCADE"???


> SET temp_buffers=3;

Setando dessa forma vc está informando ao PostgreSQL para usar ~234,38MB
= (3*8kB)/1024.

> SELECT senda.ins_mat_lev_cria_indices();
> SELECT senda.ins_mat_lev_1('98');
> SELECT senda.ins_mat_lev_2('98');
> SELECT senda.ins_mat_lev_3('98');
> SELECT senda.ins_mat_lev_4('98');
> SELECT senda.mat_marca_cliente_lev('98','LEVMAT',NULL,1256);
> 

Dificil te ajudar sem saber exatamente o que essas PLs fazem.


> Até esse ponto vai tranquilo, coisa de 5 minutos,  a próxima função
> descarrega os registros( 2 milhões) das temporáriad para as tabelas
> UNLOGGED e aí que trava de vez em quando.
> 

Precisamos de mais detalhes para poder ajudar!

Att,

-- 
   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] Diversão com restrições

2016-09-08 Por tôpico Guimarães Faria Corcete DUTRA , Leandro 
http://www.anserinae.net/fun-with-sql-constraints.html

Ponto para quem explicar sucintamente em bom português.


-- 
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] Como acompanhar execução de tarefas longas

2016-09-08 Por tôpico Rosana de Oliveira 
>
> Gostaria de saber se existe alguma consulta que estime o tempo restante do
>> processo do dump, bem como outras estatísticas, tal como existe no Oracle
>> (v$session_longops).
>> --
>> Rosana de Oliveira Santos
>>
>>
> Olá Rosana,
>
> Não há como saber o tempo restante não... Você consegue acompanhar o que
> está "acontecendo" no banco através da  tabela pg_stat_activity:
>
> SELECT * FROM pg_stat_activity
>
>
> Lucas
>


Humm... Conheço esta view Lucas. Mas a pg_stat_activity não contém as
informações que quero.
Pesquisei um pouco mais e vi que haverá facilidades deste gênero no release
9.6 do Postgresql.
  https://wiki.postgresql.org/wiki/Query_progress_indication


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

Re: [pgbr-geral] PostgreSQL-8.2 não inicia automaticamente.

2016-09-08 Por tôpico Marcos - GMail 
Pessoal, desculpa a demora a retornar. Fiz algumas tentativas para resolver
o problema, mas somente consegui utilizando o comando *pg_ctlcluster 8.2
main start*  - coloquei-o no /etc/rc.local.

Como eu estava colocando o postgresql-8.2 versão que este ano muda para 9.5
ou superior, em ubuntu-server 16 LTS, resolvi trocar para um LTS mais
antigo e que resolveu todos os problemas sem precisar incluir um comando
para força o inicio do banco.

Obrigado a todos

*Marcos Alves*

http://versosalmaepropriedade.blogspot.com.br/


Em 6 de setembro de 2016 11:13, Roberto Mello 
escreveu:

> 2016-09-06 9:52 GMT-04:00 Marcos - GMail :
>
>> Buenas pessoal, fiz instalação do postgresql-8.2 no ubuntu server
>> incluindo no source.list o seguinte repositório:
>>
>
> Pelas amor dos meus filhinhos! 8.2! Por que uma versão tão antiga? Um
> grande número de correções (algumas graves) e melhorias já foram realizadas
> desde então.
>
> *Para resolver, é preciso iniciar o banco utilizando o comando:*
>>
>> pg_ctlcluster 8.2 main start - coloquei-o no /etc/rc.local
>>
>>
> Verifique os logs para ver por que o servidor não está iniciando com os
> scripts de inicialização que acompanham o pacote. Talvez alguma
> configuração nos parâmetros de memória compartilhada? Você não muda nada
> nos arquivos de configuração padrão do pacote do PG?
>
> Roberto
>
> ___
> 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] Lentidão no Postgres 9.5

2016-09-08 Por tôpico Guimarães Faria Corcete DUTRA , Leandro 
2016-09-08 9:43 GMT-03:00 Irineu Raymundo :
>
> Estou com um problema de lentidão numa rotina, se alguém puder me dar uma
> luz do que eu poderia investigar fico imensamente agradecido.

Cadê os planos de execução?


> O banco é : "PostgreSQL 9.5.4 on x86_64-pc-linux-gnu, compiled by gcc
> (Ubuntu 5.4.0-6ubuntu1~16.04.2) 5.4.0 20160609, 64-bit"
[…]
> Até esse ponto vai tranquilo, coisa de 5 minutos,  a próxima função
> descarrega os registros( 2 milhões) das temporáriad para as tabelas UNLOGGED
> e aí que trava de vez em quando.

Que função?  Qual a definição dela (código-fonte) e quais as
estruturas dos objetos envolvidos?


-- 
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] Lentidão no Postgres 9.5

2016-09-08 Por tôpico Irineu Raymundo 

Bom dia pessoal,

Estou com um problema de lentidão numa rotina, se alguém puder me dar 
uma luz do que eu poderia investigar fico imensamente agradecido.


O banco é : "PostgreSQL 9.5.4 on x86_64-pc-linux-gnu, compiled by gcc 
(Ubuntu 5.4.0-6ubuntu1~16.04.2) 5.4.0 20160609, 64-bit"


A trava aparentemente de forma aleatória, executa 2 dias normalmente e 
parece que do nada trava na última função e fica mais de 4 horas sendo 
obrigado a derrubar.


Conferi quando trava e não tem nenhuma outra instrução que poderia faz 
um lock nas tabelas.


Basicamente ela cria tabelas temporárias, faz os cálculos necessários e 
escreve numa tabela não logada(UNLOGGED) para poder imprimir o relatório 
via ODBC.
Essa tabela fica com mais ou menos 2 milhões de registros, e tem uns 11 
índices.


Segue abaixo a rotina:

TRUNCATE senda.ind_03_03_04_01_lev CASCADE;
TRUNCATE senda.ind_03_03_04_01_01_lev CASCADE;
TRUNCATE senda.ind_03_03_04_01_01_a1_lev;
REINDEX TABLE senda.ind_03_03_04_01_lev;
VACUUM FULL ANALYZE senda.ind_03_03_04_01_01_lev;
VACUUM FULL ANALYZE senda.ind_03_03_04_01_01_a1_lev;
VACUUM FULL ANALYZE senda.ind_03_03_04_01_lev;
VACUUM FULL ANALYZE senda.ind_03_03_03_02_oc;
SET temp_buffers=3;
SELECT senda.ins_mat_lev_cria_indices();
SELECT senda.ins_mat_lev_1('98');
SELECT senda.ins_mat_lev_2('98');
SELECT senda.ins_mat_lev_3('98');
SELECT senda.ins_mat_lev_4('98');
SELECT senda.mat_marca_cliente_lev('98','LEVMAT',NULL,1256);

Até esse ponto vai tranquilo, coisa de 5 minutos,  a próxima função 
descarrega os registros( 2 milhões) das temporáriad para as tabelas 
UNLOGGED e aí que trava de vez em quando.



Irineu Raymundo

Senda engenharia de Dados.

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