Re: [pgbr-geral] "orientado a banco de dados"

[Guimarães Faria Corcete DUTRA , Leandro]

2018-01-03 14:34 GMT-02:00 Alessandro Lima :
> Realmente a maioria dos desenvolvedores é contra, mas faço parte do 1%
> Prefiro toda regra de negócio no banco de dados, priorizando a performance

Na verdade, mais do que desempenho, a principal vantagem é a
consistência de dados.  Ainda mais quando se tem o cuidado de manter o
máximo de restrições de integridade no modelo de dados,
preferencialmente declarativamente mas alternativamente na forma de
restrições de verificação (CHECK CONSTRAINTs).  Em grande parte, as
(significativas) vantagens de desempenho decorrem da consistência de
dados ocorrer no próprio SGBD.


-- 
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] PostgreSQL o DBMS do ano do DB engines.

[Guimarães Faria Corcete DUTRA , Leandro]

Maior crescimento de popularidade, embora ainda falte um bocado para
alcançar o terceiro lugar:

https://db-engines.com/en/blog_post/76


-- 
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] Sobre a história dos bancos de dados

[Guimarães Faria Corcete DUTRA , Leandro]

2017-10-30 10:56 GMT-02:00 centrisco...@gmail.com :
> Isso não lembra o lema da Microsoft fim anos 1980 e 1990? Abraçar e
> estender?

Nunca foi um lema oficial, de acordo com a Wikipédia
, mas
nunca deixou de ser uma realidade.  Se ainda usam a frase
internamente, boa questão.


-- 
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] Agrupar bancos de dados replicado num único Banco

[Guimarães Faria Corcete DUTRA , Leandro]

2017-06-21 18:37 GMT-03:00 Ivanelson Nunes :
>
> São todos iguais... Em todos os BD's de origem é o mesmo nome de esquema,
> mesmas tabelas, mesmas colunas, etc

Então o pgLogical não deve funcionar, a menos que se mude isso.
Talvez olhar o Bucardo ou algo semelhante?


-- 
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] RES: RES: REF: Constraint Check por coluna e por tabela.

[Guimarães Faria Corcete DUTRA , Leandro]

2017-01-20 13:09 GMT-02:00 Paulo :
>>Na verdade só o nome difere.  O objeto criado é o mesmo.
>
> Sim, isso eu sei.

Então não entendi qual a dúvida.  Se o objeto criado é o mesmo (uma
restrição de integridade que impede a nulidade dum atributo), e apenas
um tem nome automático e o outro nome atribuído, o que resta a
analisar?


> Mas o comportamento do banco, muda alguma coisa ?

Por que mudaria?  Só por causa do nome da restrição?  É óbvio que é
melhor ter um nome explicitamente definido, mas isso nada tem a ver
com o comportamento nem da base de dados, nem do SBGD.


-- 
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] RES: REF: Constraint Check por coluna e por tabela.

[Guimarães Faria Corcete DUTRA , Leandro]

2017-01-20 12:02 GMT-02:00 Paulo :
>
> nome character varying(60) NOT NULL UNIQUE,  aqui
[…]
> CONSTRAINT uq_nome UNIQUE (nome ))   aqui

Na verdade só o nome difere.  O objeto criado é o mesmo.


-- 
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] REF: Constraint Check por coluna e por tabela.

[Guimarães Faria Corcete DUTRA , Leandro]

2017-01-20 11:05 GMT-02:00 Paulo :
>
> Qual a principal implicação no banco e na APP entre uma CONSTRAINT CHEK a
> nível de coluna e por tabela ?

Paulo, eu particularmente acho muito difícil responder uma pergunta
tão geral.  Poderias ser mais específico, talvez com exemplo e questão
direta?


-- 
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] not null if

[Guimarães Faria Corcete DUTRA , Leandro]

2017-01-19 23:49 GMT-02:00 Tiago José Adami :
>
> Como disse o Dutra, toquemos o barco, e esqueçamos o ocorrido.

Entendido agora, obrigado!  Fiquei preocupado de ter entendido algo
errado e estar dando conselho inadequado.  Boa sexta para todos, e que
ninguém precise ficar de babá de servidor no fim de semana!


-- 
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] not null if

[Guimarães Faria Corcete DUTRA , Leandro]

2017-01-19 18:09 GMT-02:00 Tiago José Adami :
>
> Acredito não ser um problema de entendimento das formas normais, a sua
> primeira resposta ao OP deu a entender que apenas com a normalização o
> problema descrito seria resolvido sem a necessidade de implementar
> regras adicionais. Agora está claro. Agradeço pela atenção.

Acho que agora eu quem boiei, mas toquemos o barco!


-- 
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] not null if

[Guimarães Faria Corcete DUTRA , Leandro]

2017-01-19 16:07 GMT-02:00 Tiago José Adami :
>
> Apesar do OP ter satisfeito sua necessidade, vou insistir nesta
> questão. Não consegui visualizar como 'obrigar' através de uma tabela
> complementar o valor em um atributo ser not null

Talvez não tenhamos sido suficientemente claros.  A idéia não é criar
uma tabela complementar, mas normalizar; em outros termos, pegar uma
situação em que (aparementemente) há mais de uma entidade ‘misturada’
(representada) por uma única relação, e transformá-la em duas (ou
mais) relações, eliminando a possibilidade de anomalias de
atualização.

A tua pergunta dá a entender que você ainda não entendeu bem o que são
as formas normais e a normalização?  Ou foi só mesmo nossas
explicações sobre este caso que não foram claras?


-- 
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] not null if

[Guimarães Faria Corcete DUTRA , Leandro]

2017-01-19 10:55 GMT-02:00 Rafael Sousa :
> é possivel colocar um not null apenas se outro campo for por exemplo true ?

Sim, por exemplo com gatilhos, mas não seria um erro de normalização?
Não seria ideal normalizar?  De qualquer maneira, a idéia que já deram
de uma restrição de integridade é bem razoável, talvez até ideal.


-- 
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] NOSQL baseado em PostgreSQL

[Guimarães Faria Corcete DUTRA , Leandro]

2017-01-05 11:40 GMT-02:00 Vinícius Aquino do Vale :
>
> Recentemente encontrei um Database cuja a interface SQL dele é baseada na do
> PostgreSQL

Pelo jeito, não apenas a interface; parece ser mais um produto
derivado, como já houve (e creio que ainda há) com propostas análogas.
Pelo menos diz diz que é livre, embora eu não tenha verificado se a
licença é de fato livre, e sendo livre se é compatível com a original,
se é esquerdo de cópia (incompatível, mas até preferível em minha
reles opinião), ou algo incompatível.


> e o conceito dele é ser um database SQL

Diz em https://www.cockroachlabs.com/docs/frequently-asked-questions.html
que é chave-valor, e não entendo bem como um chave-valor pode ser SQL,
mas deve ser apenas ignorância minha.

Normalmente o destino desses sistemas derivados é terem suas funções e
vantagens incorporadas a alguma versão futura do PostgreSQL, e nesse
sentido é ótimo que apareçam; na minha opinião, que não é a dos
desenvolvedores do PostgreSQL, essa seria uma vantagem de eventual
migração para um esquerdo de cópia, mas mesmo como está tem funcionado
razoavelmente bem, evitando a tragédia do comuns
.

Seria interessante alguém de fora analisar e comparar tanto com outros
derivativos, quanto com o que se faz e se planeja fazer no próprio
PostgreSQL, e principalmente se eles pretendem contribuir, como e o
quê exatamente.

Reparei que dizem que se inspiraram no Google Spanner
, que apesar do
óbvio erro tanto dos desenvolvedores quanto do artigo da Wikipaedia é
ao menos mais relacional que o SQL, justamente pelo motivo que eles
dizem que o desqualificaria como relacional.  Nesse sentido, apesar
das boas bases tanto de código (PostgreSQL) quanto de inspiração
(Spanner), o resultado seria inferior conceitualmente, justamente por
não ser (¿tão?) relacional, mas mais prático no curto prazo, por ser
mais próximo do ISO SQL e do PostgreSQL.


-- 
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] Erro compilando fontes Postgresql

[Guimarães Faria Corcete DUTRA , Leandro]

2017-01-03 16:30 GMT-02:00 Flaudísio Tolentino :
>
> Legal, cara! Espero que tenha sucesso no seu trabalho e admiro sua
> pré-disposição em contribuir de volta, especialmente com algo validado por
> toda a metodologia requerida para um trabalho acadêmico - o que
> definitivamente pode incluir usar uma versão mais antiga de um software.

Bom tocar nesse ponto.  Há um descasamento entre a comunidade e
processos academicos e o processo (e comunidade) do PostgreSQL.  Temos
um caso famoso no Brasil de um professor que desenvolveu uma funçao
potencialmente importante (índices hipotéticos para o otimizador,
viabilizando estimativa de utilidade de índices e até criaçao
automática de índices, se nao me falha a memória), e por causa desse
descasamento essa funçao ficou anos parada.  A equipe academica e a
equipe do PostgreSQL nao conseguiam colaborar; cada um tinha seus
métodos e culturas e nao conseguia investir em ‘andar a segunda milha’
com o outro.

Por isso perguntei se essa idéia já foi aventada com a comunidade.

Nao que somente o que seria aceito pela comunidade tem validade
academica, mas certamente o ideal seria tentar conciliar; minha
impressao (e nao passa disso) é que caberia aos academicos se
inserirem na comunidade e se fazerem aceitos.  Um pouco como o núcleo
Linux trabalha, também.


-- 
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] Erro compilando fontes Postgresql

[Guimarães Faria Corcete DUTRA , Leandro]

2017-01-03 15:53 GMT-02:00 Neto pr :
> Pretendo verificar se as modificações realizadas desde a versão 9.0.1
> até a atual, modificaram muito o modelo de custos do postgresql, pois
> o Patch que estou aplicando, modifica funções de custos, para que
> estimativas sejam mais realistas em ambientes com discos SSDs. Caso
> tenha sido alterado algo significativo ai sim pretendo testar em
> versões mais recentes.

Nao é trivial validar desempenho, pela variedade de situaçoes com que
o otimizador tem de lidar.  Nao sei que recursos estao aa tua
disposiçao, mas eu abordaria diferentemente: dado que já há um
trabalho original mas cuja repetiçao é desinteressante (por
potencialmente obsoleto), eu verificaria se os mecanismos que ele
alterou na 9.0.1 permanecem na v10 (em desenvolvimento), e se essas
idéias foram aventadas na comunidade de desenvolvedores do PostgreSQL
desde entao.


-- 
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] Erro compilando fontes Postgresql

[Guimarães Faria Corcete DUTRA , Leandro]

2017-01-03 15:46 GMT-02:00 Neto pr :
>
> perdão, mas o seria OP ?

/Original poster/, literalmente ‘publicador original’.  No caso,
consulente original, ou seja, quem começou a discussao.


-- 
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] Erro compilando fontes Postgresql

[Guimarães Faria Corcete DUTRA , Leandro]

2017-01-03 13:21 GMT-02:00 Euler Taveira <eu...@timbira.com.br>:
> On 02-01-2017 14:10, Guimarães Faria Corcete DUTRA, Leandro wrote:
>> Pergunto-me qual a validade de experimentar questoes de desempenho
>> numa versao tao obsoleta, sendo que quase todas as versoes do
>> PostgreSQL trazem bons avanços.  Creio que seria mais relevante
>> aplicar isso aa v. 10.
>>
> A vantagem é comparar laranja com laranja; mesmo se você disser que
> 9.0.23 não houve avanços de performance.

Nao fui claro.  Nao penso na 9.0.23 como ‘nova versao’, embora
tecnicamente o seja, mas correçao de defeitos.


> Contudo, concordo com o Dutra que vale a pena experimentar uma versão
> recente (9.6.1) para apresentar valores mais atuais (já que a versão
> 9.0.1 é de 04/10/2010 -- mais de 6 anos atrás).

Aliás, esse remendo que o colega aplicou, nao há discussoes nesse
sentido para algum futuro próximo?


-- 
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] Erro compilando fontes Postgresql

[Guimarães Faria Corcete DUTRA , Leandro]

2017-01-01 3:20 GMT-02:00 Neto pr :
> Guimaraes, sobre  patch,  ele implementa o que esta descrito neste paper:
>
> http://dl.acm.org/citation.cfm?id=2236588

Ou seja, altera o otimizador para saber mais a respeito do
armazenamento em memória nao-volátil, certo?


> Estou desenvolvendo uma pesquisa,no qual sera necessario que o
> Postgresql tenha  essas caracteristicas, que o patch prove,
> modificando o codigo fonte  original. Nao posso migrar para  a ultima
> versao do Postgreesql, devido a questoes do meu trabalho de pesquisa,
> tem  que ser o postgreSQL 9.0.1 com o patch aplicado.

Pergunto-me qual a validade de experimentar questoes de desempenho
numa versao tao obsoleta, sendo que quase todas as versoes do
PostgreSQL trazem bons avanços.  Creio que seria mais relevante
aplicar isso aa v. 10.



-- 
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] Erro compilando fontes Postgresql

[Guimarães Faria Corcete DUTRA , Leandro]

2016-12-31 21:58 GMT-02:00 Neto pr :
> Eu preciso dessa versão 9.0.1, pois um pesquisador da alemanha me
> enviou, para ajudar na minha pesquisa de Pós-graduação.

Te enviou o quê exatamente?


> O patch altera
> o postgreSQL para diferenciar características  entre HDD e SSD. É para
> fins de pesquisa que estou utilizando.

Como assim?  Não ficou claro, não para mim ao menos.  Continua
parecendo fechamento cognitivo prematuro, quando a pessoa quer a
resposta à pergunta errada.

Está parecendo mais fácil portar para a última versão?


-- 
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] Erro compilando fontes Postgresql

[Guimarães Faria Corcete DUTRA , Leandro]

2016-12-31 19:54 GMT-02:00 Neto pr :
>
> Acho que a dúvida é mais relacionada ao S.O. Linux no entanto o
> Posgresql é parte do problema que estou enfrentando.

Acho que terás mais ajuda na lista do SO.  Detalhe, Linux é só o
núcleo; tua dúvida é de uma distribuição GNU/Linux.


> Tenho que compilar o SGBD Postgresql 9.0.1 que tem um Patch para esta
> versão

Como assim?  Versão mais que obsoleta.  Que remendo (/patch/) é esse?
Porque você precisa disso, afinal?  Parece um problema de fechamento
cognitivo prematuro.


> Alguém poderia me auxiliar em como eu poderia instalar compilar o
> Debian 9.0.1 no Debian 8, ou como instalar o gcc 4.7 no debian 8 ? Eu
> estou tentando fazer em uma VM para não desconfigurar o SO instalado
> num servidor HP-ML110, mas após eu fazer o teste com sucesso, irei
> aplicar o procedimento no servidor.

Compile na máquina virtual, não?


-- 
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] Ref: SQL de Profissoes.

[Guimarães Faria Corcete DUTRA , Leandro]

Le 21 déc. 2016 11:11, "Paulo"  a écrit :
> Alguém conhece ou tem o link de onde posso baixar as profissões em SQL ?

Poderias ser mais preciso e claro?

Se for o que estou pensando, já discutimos longamente nesta lista (ou
sua antecessora no Yahoo, creio) há alguns anos.


-- 
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] Forma de resolver um travamento

[Guimarães Faria Corcete DUTRA , Leandro]

2016-12-14 14:37 GMT-02:00 Leonardo Coleraus :
>
> Boa Tarde Amigos,

Em vez de formatar, pode escrever texto simples mesmo, mas escreva
corretamente, com pontuação e, se possível, acentuação.  Fica melhor
para lermos, entendermos e, se pudermos, ajudarmos.


-- 
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] Instalação do PostgreSQL em Mac

[Guimarães Faria Corcete DUTRA , Leandro]

2016-12-14 14:25 GMT-02:00 Danilo Silva :
>
> Vocês teriam um tutorial de instalação do postgres no mac (versão yosemite)?
>
> Qual a melhor forma de instalar?

Provavelmente há pouquíssima gente aqui que faz isso.  Eu
particularmente olharia o brew.


-- 
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] LOCALE Portuguese_Brazil.1252 NO LINUX CentOS 7

[Guimarães Faria Corcete DUTRA , Leandro]

2016-12-01 12:11 GMT-02:00 Eduardo Az - EMBRASIS <eduard...@embrasis.com.br>:
>
> Em 01/12/2016 11:30, Guimarães Faria Corcete DUTRA, Leandro escreveu:
>>
>> 2016-12-01 10:39 GMT-02:00 Eduardo Az - EMBRASIS
>> <eduard...@embrasis.com.br>:
>>
>> Alguma razão para usar 32 bits?  Em x86, o recomendado é 64.
>>
> A MÁQUINA É 32 BITS

Caramba, há tempos não escuto falar de māquinas 32 bits.  Apesar delas
economizarem memória e serem preferíveis em Risc abaixo de 4 Gio, a
ineficiência da arquitetura x86-32 as tornou obsoletas mesmo com menos
memória.  E em bases de dados, então, que geralmente queremos mais
memória…


>> Mas por quê não usar o sistema de pacotes da distribuição?  Se pedes
>> ajuda, ao menos explique-se.
>>
> Costume de usuário ruindows, gosto de interface gráfica.

Certo, mas veja que isso vai te dar mais trabalho do que os pacotes
nativos a médio e longo prazos.


> Os caracteres acentuados são trocados
> ç vira ¬ , á vira § e assim por diante

Isso está parecendo mais bagunça de configuração de cliente.  Veja que
a codificação tanto na origem quanto no destino é Unicode UTF-8,
portanto não deveria dar problema algum.  As configurações LC existem
apenas para ordenação (/collate/) e para compatibilização com sistemas
legados (Win1252, ISO 8859 ) via conversão de e para Unicode.


> CREATE DATABASE teste
>   WITH OWNER = eduardoaz
>ENCODING = 'UTF8'
>TABLESPACE = pg_default
>LC_COLLATE = 'Portuguese_Brazil.1252'
>LC_CTYPE = 'Portuguese_Brazil.1252'
>CONNECTION LIMIT = -1;

Isso são apenas convenções de cada sistema.  Em sistemas Posix, não
falamos em Portuguese_Brazil.1252, mas em pt_BR.  Mas pode funcionar,
desde que teu SO tenha sido configurado para isso; no caso, costuma
haver um pacote chamado locales ou algo assim, derivado da GNU libc, a
glibc.  Não lembro como é isso no CentOS, eu (e muita gente nesta
lista) uso Debian, onde essas coisa são melhor organizadas e
documentadas.  Só que não dá para misturar codificações.


> https://listas.postgresql.org.br/pipermail/pgbr-geral/2012-March/030100.html

Cara, quatro anos e meio atrás… e você ainda interpretou errado o que
o colega disse.  Ele falou que ia experimentar, e o Flávio pareceu
dizer que MS Win 1252 e ISO 8859-1 equivaliam, mas como podes
verificar em http://www.i18nqa.com/debug/table-iso8859-1-vs-windows-1252.html
isso não procede.


> Corrigi, deu erro, porem diferente:
>
> CREATE DATABASE teste
>   WITH OWNER = eduardoaz
>ENCODING = 'UTF8'
>TABLESPACE = pg_default
>LC_COLLATE = 'pt_BR.ISO-8859-1'
>LC_CTYPE = 'pt_BR.ISO-8859-1'
>CONNECTION LIMIT = -1;
>
> ERROR:  encoding "UTF8" does not match locale "pt_BR.ISO-8859-1"
> DETAIL:  The chosen LC_CTYPE setting requires encoding "LATIN1".
> ** Error **
>
> ERROR: encoding "UTF8" does not match locale "pt_BR.ISO-8859-1"
> SQL state: 22023
> Detail: The chosen LC_CTYPE setting requires encoding "LATIN1".

Exato.  Você está misturando duas codificações diferentes, a ISO 8859
e a Unicode.  Deixe tudo na base em Unicode e configure os clientes e
usuários que precisarem de ISO ou Win.



-- 
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] Recomendações sobre uso de tipos compostos

[Guimarães Faria Corcete DUTRA , Leandro]

2016-12-01 11:30 GMT-02:00 Márcio A. Sepp :
>
> Quais os prós e contras de usar tipos compostos em campos da chave primária?

Você quer dizer tipos compostos nas chaves primárias, ou chaves
primárias compostas?

De qualquer maneira, são dois jeitos de usar chaves naturais, o que é
absolutamente necessário.  O que não é absolutamente necessário é que
a chave primária seja natural; em casos extremos, pode ser necessário
usar uma chave artificial além da(s) natural(is).

Talvez se você exemplificasse o que pensou em fazer, e porque temeu
fazê-lo, poderíamos ajudar melhor.


-- 
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] LOCALE Portuguese_Brazil.1252 NO LINUX CentOS 7

[Guimarães Faria Corcete DUTRA , Leandro]

2016-12-01 10:39 GMT-02:00 Eduardo Az - EMBRASIS :
>
> Linux CentOS 7, 32 bits

Alguma razão para usar 32 bits?  Em x86, o recomendado é 64.


> Instalei usando o pacote de instalação do EnterpriseDB (OK, sei que tem
> gente que critica, mas, usei esse)

Mas por quê não usar o sistema de pacotes da distribuição?  Se pedes
ajuda, ao menos explique-se.


> quando crio o banco, ele vai padronizado com:

Cria como exatamente?


> ENCODING = 'UTF8'
> LC_COLLATE = 'pt_BR.utf8'
> LC_CTYPE = 'pt_BR.utf8'
>
> Porém, o locale original, do sistema que estava em windows é
> "Portuguese_Brazil.1252" e fez com que as acentuações fossem todas
> distorcidas.

Distorcido como, fazendo o quê?  /Dump/ e /restore/?  Com que
configurações (de linha de comando e de ambiente) do pg_dump e do
pg_restore, se tiver sido o caso?  E por quê você não remove esse
banco e cria um com o local da origem, ou não segue um dos inúmeros
tutoriais que ensinam a converter?


> Já vi que não consigo criar no mesmo locale do windows

Como assim, não consegue?  Tentou como?


> e não estou
> conseguindo setar o banco com
> "pt_BR-ISO-8859-1", que segundo pesquisa, seria o correto.

Que pesquisa foi essa?  Correto como assim?  Não existe correto ou
incorreto, mas mais ou menos adequado.  ISO 8859-1 é obsoleto; o ideal
geralmente é usar UTF-8 na base e cada programa cliente ou usuário usa
o que bem entender, que o UTF-8 dá conta de praticamente tudo.  Se
precisar mesmo de ISO 8859, tem o 8859-15 (se não me falha a memória)
que é praticamente a atualização do 8859-1.  Não acredite em mim,
pesquise o que lhe é mais adequado.  Mas geralmente a dor de cabeça de
mudar de 1252 para 8859 não vale a pena, melhor pular logo para
Unicode.


> Me aparece a
> seguinte mensagem:
>
> CREATE DATABASE teste
>   WITH OWNER = eduardoaz
>ENCODING = 'UTF8'
>TABLESPACE = pg_default
>LC_COLLATE = 'pt_BR-ISO-8859-1'
>LC_CTYPE = 'pt_BR-ISO-8859-1'
>CONNECTION LIMIT = -1;
>
> ERROR:  invalid locale name: "pt_BR-ISO-8859-1"
> ** Error **
>
> ERROR: invalid locale name: "pt_BR-ISO-8859-1"
> SQL state: 42809

Bom, primeiro que não existe pt_BR-ISO-8859-1, mas pt_BR.ISO-8859-1.
Segundo, se a codificação já é UTF-8, para quê ISO 8859 na base?


> Aonde encontrar explicações ou me passarem algumas dicas?

A documentação é ótima, histórico da lista tem muita coisa, e mais
dicas carecem de mais detalhes.


-- 
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] LOCALE Portuguese_Brazil.1252 NO LINUX CentOS 7

[Guimarães Faria Corcete DUTRA , Leandro]

2016-12-01 10:39 GMT-02:00 Eduardo Az - EMBRASIS :
>
> Linux CentOS 7, 32 bits

Alguma razão para usar 32 bits?  Em x86, o recomendado é 64.


> Instalei usando o pacote de instalação do EnterpriseDB (OK, sei que tem
> gente que critica, mas, usei esse)

Mas por quê não usar o sistema de pacotes da distribuição?  Se pedes
ajuda, ao menos explique-se.


> quando crio o banco, ele vai padronizado com:

Cria como exatamente?


> ENCODING = 'UTF8'
> LC_COLLATE = 'pt_BR.utf8'
> LC_CTYPE = 'pt_BR.utf8'
>
> Porém, o locale original, do sistema que estava em windows é
> "Portuguese_Brazil.1252" e fez com que as acentuações fossem todas
> distorcidas.

Distorcido como, fazendo o quê?  /Dump/ e /restore/?  Com que
configurações (de linha de comando e de ambiente) do pg_dump e do
pg_restore, se tiver sido o caso?  E por quê você não remove esse
banco e cria um com o local da origem, ou não segue um dos inúmeros
tutoriais que ensinam a converter?


> Já vi que não consigo criar no mesmo locale do windows

Como assim, não consegue?  Tentou como?


> e não estou
> conseguindo setar o banco com
> "pt_BR-ISO-8859-1", que segundo pesquisa, seria o correto.

Que pesquisa foi essa?  Correto como assim?  Não existe correto ou
incorreto, mas mais ou menos adequado.  ISO 8859-1 é obsoleto; o ideal
geralmente é usar UTF-8 na base e cada programa cliente ou usuário usa
o que bem entender, que o UTF-8 dá conta de praticamente tudo.  Se
precisar mesmo de ISO 8859, tem o 8859-15 (se não me falha a memória)
que é praticamente a atualização do 8859-1.  Não acredite em mim,
pesquise o que lhe é mais adequado.  Mas geralmente a dor de cabeça de
mudar de 1252 para 8859 não vale a pena, melhor pular logo para
Unicode.


> Me aparece a
> seguinte mensagem:
>
> CREATE DATABASE teste
>   WITH OWNER = eduardoaz
>ENCODING = 'UTF8'
>TABLESPACE = pg_default
>LC_COLLATE = 'pt_BR-ISO-8859-1'
>LC_CTYPE = 'pt_BR-ISO-8859-1'
>CONNECTION LIMIT = -1;
>
> ERROR:  invalid locale name: "pt_BR-ISO-8859-1"
> ** Error **
>
> ERROR: invalid locale name: "pt_BR-ISO-8859-1"
> SQL state: 42809

Bom, primeiro que não existe pt_BR-ISO-8859-1, mas pt_BR.ISO-8859-1.
Segundo, se a codificação já é UTF-8, para quê ISO 8859 na base?


> Aonde encontrar explicações ou me passarem algumas dicas?

A documentação é ótima, histórico da lista tem muita coisa, e mais
dicas carecem de mais detalhes.


-- 
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] Tabela Percentual alto de Tuplas marcadas como Delete

[Guimarães Faria Corcete DUTRA , Leandro]

2016-11-29 8:36 GMT-02:00 Fernando Franquini 'capin'
:
>
> talvez o cenário, são milhares de deletes e inserts diários, pode ser por
> isso.

Nah, isso aí não é nada.  A menos que sejam INSERTs & DELETEs
extraordinariamente pesados, acontecendo muito concentradamente, e em
momento crítico.  Probablilidade praticamente zero.


> E sim, vinham de uma versão antiguíssima (8.4) do PostgreSQL.

Antiga, mas quando VACCUUM já não devia ser mais problema.  O mais
provável é que na época leram coisas mais antigas ainda, e (como é
extremamente comum) aplicaram sem fundamento.


> Mas sim, farei meu teste, só tenho que planejar bem, pois será direto em
> produção.

Não tens um paralelo?


-- 
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] Tabela Percentual alto de Tuplas marcadas como Delete

[Guimarães Faria Corcete DUTRA , Leandro]

2016-11-28 9:16 GMT-02:00 Fernando Franquini 'capin'
:
>
> Sim, está desligado por opção, pois chegaram a conclusão que o AUTOVACUUM
> durante o dia atrapalha (devido o tamanho das tabelas - Mas ainda quero
> realizar uma alteração a acompanhar isso um dia), por isso é feito VACUUM em
> algumas tabelas principais durante a noite (porque é mais rápido) e VACUUM
> FULL no final de semana, sim, temos essa janela.

Geralmente esse tipo de conclusão se baseia nalguma observação falha,
por exemplo, de versão muito antiga, talvez bugada, ou de diagnóstico
incorreto ou incompleto de um problema.  Faça teu teste.


-- 
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] integrar Python e Postgres

[Guimarães Faria Corcete DUTRA , Leandro]

2016-11-11 13:45 GMT-02:00 Douglas Fabiano Specht :
>
> Utilizamos da enterprosedb pela facilidade de instalação, para nossos
> tecnicos de campos nao precisarem ter que atualizar por exemplo varias
> dependencias..(limitação tecnica nossa)

Acho que nao entendi.  Ja disseste isso antes, mas nao consegui captar
em que o Enterprise DB seria mais simples que aptitude install
postgresql.


> Certo, mas de qualquer forma deu certo utilizando o comando:
> #sudo apt-get install postgresql-contrib-9.5 postgresql-plpython-9.5 e
> automaticamente apareceu os pacotes das extensões para serem adicionadas..

Que bom, mas pode ser um risco de erro manter dois sistemas de
instalacao.  De qualquer maneira, se voce vai usar o apt para isso,
poderia usar tambem para o resto, e evitar muita dor de cabeca.

De maneira geral, se voce quer fazer algo mais simples que o apt, e'
porque ainda nao entendeu todos os problemas que ele resolve.


-- 
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] integrar Python e Postgres

[Guimarães Faria Corcete DUTRA , Leandro]

2016-11-11 11:58 GMT-02:00 Douglas Fabiano Specht :
>
> se a instalação foi efetuada pelo executavel (bin) da enterprisedb

Por que?


> e eu
> rodar a instalação dos pacotes pelo comando #sudo apt-get install
> postgresql-contrib-9.5 postgresql-plpython-9.5 ele ja faz a integração com o
> postgres?

Evite misturar dois sistemas de empacotamento.  Prefira sempre os
pacotes de sua distribuicao.  Se nao der para fazer tudo por um so
sistema, entao faca manualmente no sistema que nao permite fazer por
ele o que voce quer; no caso, se nao puder remover os da Enteprise DB
e usar tudo da distro, nem fazer tudo pela Enterprise DB, entao use as
instrucoes do pacote fonte para completar o que a Enterprise DB nao
deixa fazer.


-- 
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] Criar diagrama - modelo relacional

[Guimarães Faria Corcete DUTRA , Leandro]

2016-11-08 18:27 GMT-02:00 Euler Taveira :
> On 08-11-2016 17:23, Ronilson wrote:
>> Existe algum software free que eu possa utilizar para fazer isto?
>>
> Use o SchemaSpy [1].

Ou o pgAutodoc, ou o SQL::Fairy.


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

[Guimarães Faria Corcete DUTRA , Leandro]

2016-10-28 13:46 GMT-02:00 Douglas Fabiano Specht :
>
> centOS 6.8
[...]
> /opt/PostgreSQL/9.6/etc/sysconfig/plLanguages.config file

Pelo visto, usas um sistema de empacotamento que nao correponde a tua
distro.  Faz tempo que nao mexo com Cent OS, mas que me lembre e'
infinitamente mais facil usar os pacotes oficiais.


-- 
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] Codd, Edgar F ‘Ted’: A relational model of data for large shared data banks

[Guimarães Faria Corcete DUTRA , Leandro]

https://www.seas.upenn.edu/~zives/03f/cis550/codd.pdf

Fundamental.


-- 
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] armazenamento de imagens no Banco x File System

[Guimarães Faria Corcete DUTRA , Leandro]

2016-10-24 10:46 GMT-02:00 Eduardo Bohrer :
> Como o amigo Flavio salientou, existem prós e contras.
>
> De bate e pronto o mais recomendado seria deixar fora do banco mesmo.

Não, o que o Flávio disse, e eu concordo, é que não há ‘mais
recomendado’.  A pessoa tem de avaliar sua situação e decidir.

Se não há problemas reais e constatados, melhor deixar como estar.
Havendo problemas, aí podem-se avaliar prós e contras de mudar.  Mudar
sem saber exatamente porquê vai dar problemas novos sem que houvesse
antigos a resolver.

E na dúvida, deixe no banco.  Ele foi feito para resolver problemas,
não para criá-los.


-- 
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] Função com generate_series

[Guimarães Faria Corcete DUTRA , Leandro]

2016-10-19 11:19 GMT-02:00 Izaque Maciel :
>
> Chave artificial.
> É somente uma identificação de número controle interno, não é como um cpf ou
> rg.
> Não entendo bem, mas garantindo a unicidade do campo em questão, no caso o
> "id", já resolve. Obrigado por alertarem.

Enquanto não der outros problemas, tudo bem; mas sem uma chave
natural, você provavelmente nalgum momento terá a mesma informação
várias vezes registrada, só com ids diferentes.  Deve ser um dos
problemas mais comuns em bases de dados hoje.


-- 
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] Função com generate_series

[Guimarães Faria Corcete DUTRA , Leandro]

Não foi o que você perguntou, mas alertando para um problema potencial:


2016-10-18 15:19 GMT-02:00 Izaque Maciel :
>
> select date
> from generate_series(new.dtinicial::timestamp,
>   new.dtfinal, '1 day') date
> where extract(dow from date) not in (0,6)
>   LOOP
> INSERT INTO tarefa_itens (id, id_tarefaag, data_horafin,
>  data_horaexec, executada)
> VALUES ((select coalesce((max(ti.id) + 1), 1)
> chave from tarefa_itens ti),
>   new.id,
>   null,
> rec.date   -- Aqui
>   'N');

Essa tabela tem chave natural, ou só artificial?  Porque a artificial
não garante unicidade, e se for só ela dará problema mais cedo ou mais
tarde.


-- 
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] PG 9.6 PGADMIN

[Guimarães Faria Corcete DUTRA , Leandro]

2016-10-07 13:55 GMT-03:00 Eduardo Az - EMBRASIS :
> 1) Instalei o pg, via instalador da EDB

Esse instalador inclui o pgAdmin?


> desinstalei, ao reinstalar, o slony
> não se instala, avisando que tem instalação anterior. Diz que vai atualizar,
> mas, dá erro. (unico problema que tive com relação ao pg em si)

Que erro?  Já pesquisou por esse erro em listas de Slony?


> 2) tentar entrar em uma pasta, por exemplo, para fazer restore ou backup e
> ela não abrir, via o pgadmin.

Creio que o ideal é relatar numa lista de pgAdmin, já que ele não faz
parte do PostgreSQL.  Mas pode ser que alguém te ajude aqui também.


> 3) Restore  de banco de dados do pgadmin, está dando erro, explicando:
> -ao usar a opção restore, aparece uma caixa de mensagem com o status. Ela
> não some, apesar de fazer o restore  e os restores que tento fazer depois,
> não são feitos.
> A principio, imaginei ser problemas com meu laptop (32 bits), porém, em
> instalação em outra máquina (64 bits), acontece o mesmo.
> detalhe: desinstalei todo o PG, ao reinstalar e entrar no pgadmin, a caixa
> de mensagem continua lá, como se eu não tivesse feito nada.

Não seria o caso de buscar suporte na EDB, que criou teu instalador?


-- 
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] PostgreSQL 9.5.4 + Windows 10

[Guimarães Faria Corcete DUTRA , Leandro]

2016-10-03 14:59 GMT-03:00 Emanuel Araújo :
>> O WindowXP tem uma limitação de conexões de usuário quando se usa ele como
>> servidor ...
>
> Nao creio que seja um problema de limite de conexoes, ate porque sao poucas
> conexoes que eh usado pelo sistema, tipo < 20.

No MS-WNT Workstation, o limite era dez.


-- 
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] Depuração & pgHero

[Guimarães Faria Corcete DUTRA , Leandro]

2016-09-30 16:47 GMT-03:00 Roberto Mello <roberto.me...@gmail.com>:
>
> On Fri, Sep 30, 2016 at 12:45 PM, Guimarães Faria Corcete DUTRA, Leandro
> <l...@dutras.org> wrote:
>>
>> https://www.justwatch.com/blog/post/debugging-postgresql-performance-the-hard-way/
>
> Excelentes artigos! Grato por compartilhar!

De nada!

E obrigado por confirmar minha impressão.  Estou tão afastado do
traçado que compartilho algumas coisas até para saber se realmente é
tão bom quanto me pareceu.


-- 
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] Depuração & pgHero

[Guimarães Faria Corcete DUTRA , Leandro]

Porque hoje é sexta.

https://www.justwatch.com/blog/post/debugging-postgresql-performance-the-hard-way/

https://github.com/ankane/pghero



-- 
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] Aplicação desktop com banco de dados hospedado em VPS.

[Guimarães Faria Corcete DUTRA , Leandro]

2016-09-28 10:33 GMT-03:00 Saraiva Silva :
>
> O aplicativo não é MS Windows é Python+PyQt rodando sobre ubuntu.

Melhor ainda.  Experimente os protocolos modernos, todos gratuitos:
X11, VNC, NX… cada um se adapta melhor a determinadas situações.  Rede
local X11, NX para /modens/, VNC para o intermediário.  Creio que há
mais protocolos ainda, como implementações livres do RDP do MS
Terminal Server, talvez do protocolo do Citrix Metaframe cujo nome
sempre esqueço… falta de opção não é.


> Nunca tive esse cenário antes, mas minha esperança para achar que dará certo
> é baseado no fato de que, se fosse uma aplicação WEB toda hospedada no
> servidor e acessada no escritório através de um navegador, a quantidade de
> dados trafegadas entre o servidor e o terminal no escritório seria maior
> pois não seriam apenas os dados armazenados no banco, mas sim os queries +
> conteúdo html + imagens, etc.

Na verdade, geralmente uma aplicação Web bem feita é relativamente
leve.  Haja visto que usamos todos os dias gMail   Se o servidor
Web estiver próximo ao PostgreSQL, normalmente devia ser suficiente.


> Por se tratar de uma app desktop não existirá conteúdo de interface
> trafegando, apenas dados de queries.

Mas isso é que justamente é o mais pesado.


-- 
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] Aplicação desktop com banco de dados hospedado em VPS.

[Guimarães Faria Corcete DUTRA , Leandro]

2016-09-27 21:10 GMT-03:00 Tiago José Adami :
>
> O aplicativo Desktop é MS Windows? Existe a possibilidade de colocar
> tudo em um VPS, até o aplicativo Desktop, rodando via Terminal
> Service? O tráfego das "telas" via Terminal Server é mais eficiente
> que trafegar dados direto "no" banco.

E mais eficiente ainda quando é X11 (Posix), quando temos várias
alternativas de protocolos para fazer isso: X11 ‘nativo’ em redes
locais, NX remoto…


-- 
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] MIGRAÇÃO POSTGRESQL - LINUX (CISC) para o Solaris (RISC) - DESEMPENHO RUIM NO SOLARIS

[Guimarães Faria Corcete DUTRA , Leandro]

2016-09-23 16:31 GMT-03:00 Rosana de Oliveira :
>
> Trabalhamos com o PostgreSQL em nossa empresa.
> Precisamos migrá-lo  da  plataforma Linux  (arquitetura CISC) para a
> plataforma Unix (arquitetura RISC).  Após vários testes, estamos em dúvida
> quanto à performance da arquitetura RISC.
> Fizemos vários testes de pg_dump e de desempenho de queries.
> Em todos os testes, a plataforma Unix foi mais lenta do que a plataforma
> Linux.
>
> - Tempo pg_dump  do Linux: 5 horas
> - Tempo pg_dump  do Unix:  7 horas, 6 horas
> - Queries no Unix  - mais lentas

Esses testes são inválidos, por não aproveitarem o paralelismo da
arquitetura Sun Sparc T5.  O conceito dela é de muito mais núcleos que
os Intel, embora cada núcleo individualmente seja possivelmente mais
lento que um núcleo Intel.  Algo parecido, embora menos radical, vale
também para os AMD.

Como o PostgreSQL ainda tem pouco paralelismo interno às consultas, um
teste válido teria de ser um teste em que se simulasse uma carga real
do sistema, com vários usuários e operação simultâneos.  Dependendo do
modelo específico, o T5 terá doze ou vinte núcleos, se não me fala a
memória, cada um dedicado a uma operação diferente simultaneamente.

À medida em que progredir a implementação do paralelismo no PosgreSQL,
esses testes ficarão mais fáceis.


-- 
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] Servidor lento

[Guimarães Faria Corcete DUTRA , Leandro]

2016-09-17 15:39 GMT-03:00 Antonio Cesar :
> Os discos estão normal.

O que te indicou isso?  top?  sar?  Cadê os planos de execução
problemáticos?  Se não há planos de execução problemáticos ou
mensagens de registro de atividade, impossível ajudar à distância.

Eu sugiro buscar consultoria urgente, pareces precisar de mais ajuda
do que a que podemos dar numa lista de discussões.


-- 
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] Servidor lento

[Guimarães Faria Corcete DUTRA , Leandro]

2016-09-17 14:15 GMT-03:00 Antonio Cesar :
>
> O servidor do meu cliente depois de uma queda de energia ficou muito lento

Difícil ajudar assim.  Você ainda nem verificou o básico do básico,
como a carga do sistema (pode não ser o PostgreSQL), que operações
especificamente estão lentas, eventuais planos de execução… não
sabemos nem qual o sistema operacional!


-- 
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] vacuum analyze por tabela

[Guimarães Faria Corcete DUTRA , Leandro]

2016-09-16 19:15 GMT-03:00 Luiz Henrique :
>
> Quando saber que preciso executar vacuum analyze individual por tabela ?

Não precisa, deixe o autovácuo trabalhar.


> Que parâmetros / estatísticas procurar para indicar que a tabela merece um
> vacuum ?
> Alguem tem / recomenda um select que lista isso ?

Sobre as exceções, vide o histórico da lista.  Discutimos isso não faz
tanto tempo.


-- 
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] RollBack isolado, existe?

[Guimarães Faria Corcete DUTRA , Leandro]

Por favor, limpe os cabeçalhos ao responder.


2016-09-16 13:30 GMT-03:00  :
>
> Então Dutra, como ja percebeu eu não sou DBA, rsrs, minha rotina não é em PL
> dentro do banco

Uai, e que tem isso a ver?  Não precisa ser DBA para usar os recursos
da base de dados.

Dei um exemplo em PL/pgSQL; sua linguagem deve (deveria?) oferecer
recursos semelhantes.


-- 
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] RollBack isolado, existe?

[Guimarães Faria Corcete DUTRA , Leandro]

2016-09-16 11:04 GMT-03:00  :
>
> Então Alex, o detalhe é que vão existir muitos erros (indefinidos) que vou
> tratar com o tempo e durante esse tempo tenho que manter os OK

Pressuponho que já tenhas estudado 40.6.6. Trapping Errors em
https://www.postgresql.org/docs/9.5/static/plpgsql-control-structures.html


-- 
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] RollBack isolado, existe?

[Guimarães Faria Corcete DUTRA , Leandro]

2016-09-16 10:02 GMT-03:00  :
> Esse é uma rotina muito comum, mas estou numa duvida, preciso que o sistema
> efetive os registros que não derem erro, mas como veem ele só vai efetivar a
> cada 1mil.

É só tratar os erros, as exceções.


-- 
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] Programa para imprimir as tabelas e seus relacionamentos

[Guimarães Faria Corcete DUTRA , Leandro]

2016-09-14 10:42 GMT-03:00 Danilo Silva :
>
> Quais programas existem atualmente no mercado (que funcionem para o
> PostgreSQL) que imprima as tabelas com seus campos e relacionamentos, se não
> me falha a memória, quero que imprima o MER da minha base.

DER tem também os veneráveis pg_autodoc e SQL::Fairy.


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

[Guimarães Faria Corcete DUTRA , Leandro]

2016-09-08 17:15 GMT-03:00 Fabrízio de Royes Mello <fabri...@timbira.com.br>:
> 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

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

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

[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

Re: [pgbr-geral] Diferenças entre language 'plpgsql' e language 'sql'

[Guimarães Faria Corcete DUTRA , Leandro]

2016-09-02 12:42 GMT-03:00 Gustavo :
>
> eu conheço SQL só que estou aprendendo postgres

O SQL do PostgreSQL é bem mais rico do que o que se costuma usar em
outros SGBDs.


> eu até ja fiz umas coisas em PL   mais fiquei na duvida quando vi em artigo 
> falando sobre o SQL

Mas que dúvida, especificamente?  E o que dizia esse artigo?


> mais a grosso modo, a PL são para os casos mais complexos do postgres ou 
> quando quer fazer algo em outra linguagem

Mais para poder escolher a linguagem.  O SQL em si resolve muita coisa
declarativamente.  O procedural não é tão mais poderoso que o
declarativo quanto pode parecer à primeira vista.


> e a SQL seria mais para queries de consulta onde não há necessidade de algo 
> mais complexo...

Não, SQL faz praticamente tudo, principalmente quando usado como uma
sublinguagem de dados.  Por exemplo, foi concebido inicialmente para
usar junto com Cobol.


> pelo que vi o PL usa mais recuso do servidor... por isso a preocupação..

Sim, mas essa é a natureza da programação procedural.  Por isso, entre
outras razões, é bom sempre pensar primeiro declarativamente, e só
passar para o procedural quando não tiver outro jeito.

E as PLs, embora consumam recursos do servidor, ainda são mais
eficientes, por rodarem no SGBD, que o SQL como sublinguagem de dados
num processo externo; por exempo, PL/Java tenderá a ser mais eficiente
que SQL dentro do Java fora do SGBD.


-- 
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] Recuperação rápida com preservação de transações?

[Guimarães Faria Corcete DUTRA , Leandro]

2016-09-02 11:48 GMT-03:00 Flavio Henrique Araque Gurgel :
>
> Quem sabe uma PgConzinha com um belo caso de uso?

Dentro!  Depois de seis anos e meio de burocracia, estou muito a fim
de voltar à vida (técnica).


> A transação preparada sobrevive a falhas do serviço de banco de dados ou do
> servidor. Uma réplica (ou mesmo o antigo mestre reinicializado) guarda a
> transação no estado em que ela estava. Exemplo :
> Servidor principal:
> BEGIN;
> PREPARE TRANSACTION  xxx; --xxx é seu identificador
> INSERT...
> UPDATE...
> DELETE...
> --CRASH--
>
> Sobe o servidor secundário (previamente em replicação síncrona):
> COMMIT PREPARED xxx;
> Continua a vida.

Bonito.


> Note que esta implementação tem várias nuances, por exemplo, existe o risco
> de "esquecer" a transação aberta e isso tem custos altos (como tuplas que
> não são recuperadas pelo autovacuum, bloqueios que não são liberados, etc),
> logo, a aplicação tem que ser bem escrita.

A aplicação é nossa, então isso não seria problema, em princípio.


>> > já garante o requisito se em replicação síncrona.
>>
>> Quiseste dizer sem replicação síncrona?
>
> Não, a replicação *tem de ser síncrona* senão você corre o risco de não ter
> algo replicado a tempo e o usuário não poderá continuar o que estava
> fazendo.

Agora entendi.  Não consegui entender a tua frase, achei que fosse
erro de digitação (em tempos de teclados de celular…)


> Isso tem um impacto no desempenho, evidentemente.

Provavelmente é irrelevante.  Nossas maiores bases são muito pequenas,
e essa é minúscula.


>> > Você precisará de algo pra fazer o fail-over automático, algumas
>> > soluções
>> > que me vêm à cabeça são o clássico pgpool2 ou o moderno Patroni em
>> > https://github.com/zalando/patroni
>>
>> Pesquisaremos, obrigado!

Caramba, etcd e CoreOS… estou muito desatualizado!  Nem sei por onde começar aí.


> Calma lá, analise todos os requisitos, até aqui você nos deu um pedaço do
> bolo. Possível, digamos que é, claro. Mas são muitas variáveis, acho que
> cabe um estudo e um POC bem caprichado (o governo adora POC ;) ) e uma boa
> consultoria seria de bom tom, mas isso você sabe e já até falou.

Os colegas que têm 'todos os requisitos' estão em cópia, espero que
entrem na comunidade.  Mas de qualquer maneira conversaremos
internamente.


-- 
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] Diferenças entre language 'plpgsql' e language 'sql'

[Guimarães Faria Corcete DUTRA , Leandro]

2016-09-02 11:58 GMT-03:00 Flavio Henrique Araque Gurgel :
>> o Oracle.  Para portabilidade e padronização, prefira o PL/pgPSM; mas
>> há várias outras PLs a gosto, como PL/Python, PL/Java, PL/Ruby…
>>
> Desculpe intervir

Não precisa se desculpar, tuas intervenções são sempre adequadas e,
freqüentemente, essenciais.


> mas, até onde sei, a proposta de integrar PL/pgPSM ao
> PostgreSQL não andou muito desde a versão 9.3 quando foi proposta por alguém
> que não lembro.
> A página da versão externa está às moscas no pgFoundry e em fase alfa.
> Posso estar errado, perdi algum bonde?

Não está errado.  É o padrão SQL, mas na prática PL/Java e PL/pgSQL
podem ser mais portáveis.


-- 
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] Diferenças entre language 'plpgsql' e language 'sql'

[Guimarães Faria Corcete DUTRA , Leandro]

2016-09-02 12:27 GMT-03:00 Sebastian Webber :
>
> Em 2 de setembro de 2016 12:02, Gustavo 
> escreveu:
>>
>> mais para eu fazer uma simples validação de dados BEFORE antes da
>> gravaçao...  faço em SQL ou PLPgSQL ?
>> é um simples if para saber se o valor é valido ou não...
>
> Nesse caso, utilize plpgsql. Veja a doc[1] com exemplos e maiores detalhes.

Não, prefira o CHECK VALIDATE.   Validações em PLs é só para os casos
(não tão freqüentes na prática) em que as restrições de integridade
declarativas não são suficientes.  Como aliás a resposta do Gurgel já
indicou.


-- 
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] Diferenças entre language 'plpgsql' e language 'sql'

[Guimarães Faria Corcete DUTRA , Leandro]

2016-09-02 12:32 GMT-03:00 Gustavo :
>
> Então para obter uma simples lista de produtos..  posso usar o language SQL ??

Deve.

Faça o seguinte.  Pegue o Chris Date, _Introdução a sistemas de bancos
de dados_.  E leia.

Se precisar de algo mais rápido, pegue algum tutorial de SQL.  Para
brincar, tem bases de amostra para testes no PostgreSQL.

Depois que já se tiver familiarizado com SQL escolha alguma PL e brinque.


-- 
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] Diferenças entre language 'plpgsql' e language 'sql'

[Guimarães Faria Corcete DUTRA , Leandro]

2016-09-02 11:20 GMT-03:00 Gustavo :
>
> duvidas e as diferenças do plpgsql e sql

SQL: linguagem declarativa de manipulação de estruturas e dados.

PL/pgSQL: linguagem procedural para programação, usando SQL.


> 1. Alguém pode me dar um exemplo pratico em que momento utilizar o plpgsql e 
> o sql ?

SQL usas interativamente ou dentro de programas de outras linguagens,
como Python, Ruby…

PL/pgSQL é um derivado de Ada que é a linguagem de programação padrão
para aplicativos e procedimentos armazenados no PostgreSQL, espelhando
o Oracle.  Para portabilidade e padronização, prefira o PL/pgPSM; mas
há várias outras PLs a gosto, como PL/Python, PL/Java, PL/Ruby…


-- 
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] Recuperação rápida com preservação de transações?

[Guimarães Faria Corcete DUTRA , Leandro]

2016-09-02 10:54 GMT-03:00 Flavio Henrique Araque Gurgel :
>
>> Um colega me colocou um requisito para viabilizar uma migração de
>> Oracle com retrabalho e investimentos mínimos.
>
> Que desafio bonito!

Sendo para o setor público, acho que fica lindo.  Pode virar um caso
para apresentação; apesar de ser pequeno, é muito crítico (para o
Brasil!) e será muito visível.


>> Temos um sistema onde o usuário espera não ter de reiniciar uma
>> transação mesmo com falha de um servidor, desde que outro possa
>> automaticamente continuá-la num intervalo de até quinze segundos.
>> Quais seriam os componentes mais indicados para essa situação em
>> PostgreSQL hoje?  PostgresXL, PostgresXC, pg_pool?  Perdoem a
>> ignorância, estou muito enferrujado mesmo.
>
> Eu vejo algo mais como transações preparadas e replicação ordinária

Poderia explicar melhor?  Estou muito enferrujado mesmo, e o colega
não é familiarizado com PostgreSQL.  Pelo que estou entendendo, as
transações preparadas (efetivação em duas fases) serviriam para que a
réplica entre no ar como principal com a transação efetivada, confere?


> já garante o requisito se em replicação síncrona.

Quiseste dizer sem replicação síncrona?


> Você precisará de algo pra fazer o fail-over automático, algumas soluções
> que me vêm à cabeça são o clássico pgpool2 ou o moderno Patroni em
> https://github.com/zalando/patroni

Pesquisaremos, obrigado!


> Acho que o conceito pode ser provado sim.

Não sabes como isso me deixa feliz!


-- 
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] Recuperação rápida com preservação de transações?

[Guimarães Faria Corcete DUTRA , Leandro]

Bom dia!

Um colega me colocou um requisito para viabilizar uma migração de
Oracle com retrabalho e investimentos mínimos.

Temos um sistema onde o usuário espera não ter de reiniciar uma
transação mesmo com falha de um servidor, desde que outro possa
automaticamente continuá-la num intervalo de até quinze segundos.
Quais seriam os componentes mais indicados para essa situação em
PostgreSQL hoje?  PostgresXL, PostgresXC, pg_pool?  Perdoem a
ignorância, estou muito enferrujado mesmo.

O nosso custo de Oracle para esse sistema é muito baixo hoje; o motivo
da migração é se livrar da trabalheira que o Oracle produto, e a
Oracle empresa, dão.  Mas há uma oportunidade de negócio porque
provavelmente contrataremos suporte para o PostgreSQL, caso consigamos
provar o conceito.


-- 
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] quando usar vacuum full analyze

[Guimarães Faria Corcete DUTRA , Leandro]

2016-09-01 8:32 GMT-03:00 Luiz Henrique :
>
> Segue anexo os planos da consulta. Obrigado pela ajuda

Por favor prefira colocar informações em texto simples no corpo da
mensagem, facilita para todos.


-- 
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] RES: Dúvida sobre sistema operacional para banco de dados PostgreSQL

[Guimarães Faria Corcete DUTRA , Leandro]

2016-08-30 17:49 GMT-03:00 itamar <ita...@ispbrasil.com.br>:
>
> On 08/30/2016 05:44 PM, Guimarães Faria Corcete DUTRA, Leandro wrote:
>>
>> É que é uma distro proprietária de código livre.  A parte do código
>> livre é legal, e permite o Cent OS e outros equivalentes; mas mesmo
>> isso viola a letra da homologação.  Prefiro buscar liberdade completa,
>> portanto Debian, mesmo que isso obrigue a alguma gambiarra de quando
>> em vez.
>>
> e o debian pagava o salario do Tom Lane até alguns anos atrás ?

Bom ponto.  Mas não paga mais.  Está na hora de recuperarmos liberdade
e flexibilidade, e acabar com essa farsa da homologação.  Que aliás é
uma das coisas que sustenta a Oracle.


-- 
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] RES: Dúvida sobre sistema operacional para banco de dados PostgreSQL

[Guimarães Faria Corcete DUTRA , Leandro]

2016-08-30 17:40 GMT-03:00 Flaudísio Tolentino <flaudi...@gmail.com>:
> 2016-08-30 14:29 GMT-03:00 Guimarães Faria Corcete DUTRA, Leandro
> <l...@dutras.org>:
>>
>> Mas veja que o CentOS também não é oficial.  Essa minha irritação contra o
>> RH.
>
> Sinceramente não entendi a irritação com o RHEL em si. Se a fabricante não
> suporta o CentOS, mesmo que binariamente compatível (por isso o "oficial"
> entre aspas), você deve se irritar com ela, não com a distro... a não ser
> que estou deixando algo passar, hehe.

É que é uma distro proprietária de código livre.  A parte do código
livre é legal, e permite o Cent OS e outros equivalentes; mas mesmo
isso viola a letra da homologação.  Prefiro buscar liberdade completa,
portanto Debian, mesmo que isso obrigue a alguma gambiarra de quando
em vez.


-- 
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] RES: RES: Dúvida sobre sistema operacional para banco de dados PostgreSQL

[Guimarães Faria Corcete DUTRA , Leandro]

2016-08-30 14:39 GMT-03:00 Santiago - NSR :
> Sempre usei DELL com debian. Acontece que a DELL não tem "homologado" Debian 
> apenas REDHAT que eles mesmos vendem ($)

Incompatibilidades Dell supreender-me-iam, visto que eles suportam
Ubuntu, que nada mais é que um Debian de testes metido a besta.  Mas
sempre há risco.


-- 
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] RES: Dúvida sobre sistema operacional para banco de dados PostgreSQL

[Guimarães Faria Corcete DUTRA , Leandro]

2016-08-30 14:01 GMT-03:00 Flaudísio Tolentino :
> Não é incomum que servidores de fabricantes como IBM/Lenovo não tenham
> nenhum Debian-like na lista de SOs oficialmente compatíveis (infelizmente).

Na verdade, só a HP costumava suportar Debian, entre as grandes; não
sei como está, agora.  Creio que a Dell suporta Ubuntu LTS, mas não
tenho certeza.


> Além do mais, nunca se sabe, alguma característica específica dos RHEL-like
> pode ser mais alinhada com a finalidade do servidor.

Só mesmo em termos de homologação.  São todos Linuces.


> Mas a "escovação de bits" me preocupa: "transplantar" drivers de uma distro
> para outra me parece algo frágil que, mesmo se der certo (e não duvido que
> dê), pode ser complicado pra documentar e manter, além de ser um
> conhecimento que tende a ficar muito restrito. Exemplo: seguir um
> procedimento padrão de instalação do CentOS vs instalar o Debian com N
> passos adicionais de como compilar/empacotar, instalar e homologar o(s)
> driver(s) necessário(s).

Concordo.  Mas às vezes vale a pena.


> Apesar de preferir Debian e Ubuntu LTS, mantenho CentOS em alguns servidores
> físicos justamente por essa "compatibilidade oficial" e manutenabilidade.

Mas veja que o CentOS também não é oficial.  Essa minha irritação contra o RH.


> Por fim, concordo com o Sebastian que a expertise da equipe vai ser decisiva
> na escolha. E ainda mais em tempos de Docker e Ansible/Puppet/Chef, acho que
> a tendência é ser quase agnóstico com distros, a não ser, como sempre, em
> casos específicos.

Lembra que esta é uma lista de PostgreSQL.  É difícil ignorar a distro
quando se lida com algo tão crítico em tantas situações.  Não será a
primeira vez que se tenta abstrair o SO, e não será a última.


-- 
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] Dúvida sobre sistema operacional para banco de dados PostgreSQL

[Guimarães Faria Corcete DUTRA , Leandro]

2016-08-30 12:40 GMT-03:00 Tiago José Adami <adam...@gmail.com>:
> Em 30 de agosto de 2016 11:11, Guimarães Faria Corcete DUTRA, Leandro
> <l...@dutras.org> escreveu:
>> Estranho.  Na pior das hipóteses, pega-se o acionador de dispositivo
>> (que tem de ser livre, em razão da GNU GPL) da distro ‘que funciona’ e
>> transfere-se para a preferida.  Ou tem algo mais complicado que isso?
>
> Havia uma controladora de discos a qual possuía os "drivers" ou
> acionadores de dispositivos de código fechado disponível apenas em
> pacotes RPM.

Se fosse questão de empacotamento, bastava abrir ou converter, é
trivial.  Mas não devia ser, devia ser compatibilidade; provavelmente
seria o caso de usar a mesma versão de núcleo e relatar para os
desenvolvedores a violação da GNU GPL, mas a solução definitiva.
provavelmente demoraria meses.


> Mesmo com muito afinco e várias tentativas não foi
> possível configurá-lo no Debian (o desempenho era horrível e o
> multipath não funcionava), talvez até por incapacidade técnica dos
> SysAdmins.

Acho bem provável a falta de capacidade.  Geralmente, é só usar núcleo
de mesma versão.


> A solução - inclusive recomendada pelo fabricante por ser
> um SO "homologado" - foi usar RHEL.

Diga qual o fabricante, para fugirmos dele.


-- 
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] Dúvida sobre sistema operacional para banco de dados PostgreSQL

[Guimarães Faria Corcete DUTRA , Leandro]

2016-08-30 11:39 GMT-03:00 Sebastian Webber <sebast...@swebber.me>:
>
> Em 30 de agosto de 2016 09:39, Guimarães Faria Corcete DUTRA, Leandro
> <l...@dutras.org> escreveu:
>>
>> O que seria EL?  RH?
>
> [Red Hat] Enterprise Linux e distros derivadas nele (Oracle Enterprise
> Linux, CEntOS, etc)
>
>> Eu recomendaria ou um Debian GNU/Linux, ou um *BSD.  Mas depende de muita
>> coisa.
>
> Concordo que é um opção, mas como não tenho experiência nessa "familia
> Linux", não a recomendei.

Acho que se pesquisares entre os membros mais ativos da comunidade
brasileira, provavelmente verás que Debian provavelmente seja a mais
popular, além de ser a mais fiel ao jeito de ser da comunidade livre —
embora a Red Hat sempre libere o código-fonte de tudo que faz ou
compra.  Mas hoje praticamente o único motivo de se usar RH ou
derivado é alguma necessidade, geralmente burocrática e irracional, de
homologação seja para algum equipamento (Dell, Lenovo…), seja para
algum programa (Oracle…).


-- 
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] Benchmark com consultas demoradas para Postgres

[Guimarães Faria Corcete DUTRA , Leandro]

2016-08-30 12:03 GMT-03:00 Vinicius Segalin :
>
> Faltou essa noção de que tipos de consultas eu posso fazer que me tragam
> essas diferentes performances que quero encontrar. O pg_bench criou a base
> de diversos tamanhos dependendo dos parâmetros utilizados, o que me retornou
> performances e resultados interessantes, mas tudo que fiz foi utilizar a
> transação padrão que o pg_bench provê. De repente se eu souber que tipos de
> consultas utilizar, em vez de apenas usar essa transação padrão, eu posso
> chegar a essa diferença de performance que busco.

Se não me falha a memória, há TPCs diferentes.  Mas não lembro se TPC
é algo que se possa rodar ‘em casa’.


-- 
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] Benchmark com consultas demoradas para Postgres

[Guimarães Faria Corcete DUTRA , Leandro]

2016-08-30 11:40 GMT-03:00 Vinicius Segalin :
>
> É para uma ideia na faculdade. E nesta ideia vou precisar saber quais
> máquina possuem melhor desempenho (e quão melhor ele é) para escolher a
> máquina para o usuário.

Os usuários são diferentes em diversos aspectos de uso que exigem
partes diferentes de equipamentos complexos; e diferentes máquinas
terão vantagens e desvantagens diferentes para cada padrão de uso de
cada usuário.  O ideal seria ver que perfis de usuários tens e testar
para esses perfis, com seus respectivos aplicativos e dados.  Testes
sintéticos de desempenho são apenas aproximações grosseiras.


> Já usei o pg_bench e tive alguns resultados legais, mas não tudo que queria.

O que faltou?


>> Não entendi.  O que te impede de rodar os mesmo testes vez após cada
>> reconfiguração?
>
> Nada. A ideia é essa mesma: rodar os mesmos testes em cada configuração. Mas
> gostaria de saber se com determinado tipo de consulta (por exemplo: com
> determinado esquema, fazendo x join's retornando a partir de y registros),
> uma máquina com mais memória teria performance significativamente melhor que
> a outra. Isso mais com objetivo de economizar meu tempo, já que se eu fizer
> consultas longas (de horas) em todas as máquinas para depois descobrir que
> essas consultas não serviram pra nada, o tempo desperdiçado teria sido
> grande (apesar de chegar a conclusão de que memória não influencia nelas).

Geralmente, cada teste sintético tem resultados publicados que podem
ser úteis para teres essa idéia.  Fuce por exemplo os TPCs; não sei se
o pg_bench tem também, mas imagino que tenha.


-- 
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] Benchmark com consultas demoradas para Postgres

[Guimarães Faria Corcete DUTRA , Leandro]

2016-08-30 10:16 GMT-03:00 Vinicius Segalin :
>
> Estou precisando fazer uns testes em máquinas com diferentes recursos para
> testar as suas performances com consultas rápidas (<1 segundo), médias
> (minutos), e longas (>1 hora). Para isso preciso de uma base e consultas que
> me possibilitem fazer isso.

Mas para quê?  Está com cara de fechamento precoce cognitivo: dize-nos
o que queres fazer, mas pode não ser o melhor para o problema que
queres resolver.


> Existe algum benchmark que me permita fazer isso
> de modo mais fácil?

Alguns.  Veja os TPCs e o pg_bench.


> E eu preciso que as consultas me retornem performances diferentes à medida
> que eu adiciono memória ou cpu na máquina. Há padrões de consultas que me
> possibilitariam isso?

Não entendi.  O que te impede de rodar os mesmo testes vez após cada
reconfiguração?


-- 
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] Dúvida sobre sistema operacional para banco de dados PostgreSQL

[Guimarães Faria Corcete DUTRA , Leandro]

2016-08-30 10:31 GMT-03:00 Tiago José Adami <adam...@gmail.com>:
> Em 30 de agosto de 2016 09:39, Guimarães Faria Corcete DUTRA, Leandro
> <l...@dutras.org> escreveu:
>>
>> Eu recomendaria ou um Debian GNU/Linux, ou um *BSD.  Mas depende de muita 
>> coisa.
>
> No "muita coisa" eu destacaria compatibilidade com o hardware. Apesar
> de não ser comum nos dias atuais já presenciei casos em que foi
> necessário trocar uma distro Linux por outra em razão deste motivo.

Estranho.  Na pior das hipóteses, pega-se o acionador de dispositivo
(que tem de ser livre, em razão da GNU GPL) da distro ‘que funciona’ e
transfere-se para a preferida.  Ou tem algo mais complicado que isso?


> Desconheço se os *BSD da vida estão atualizados neste aspecto.

Geralmente, eles têm menos suporte que os GNU/Linux, até porque o
esquerdo de cópia força a publicação do código-fonte dos acionadores
de dispositivo, embora por um lado esse código geralmente seja
facilmente portável para BSD e, por outro, a licença permissiva acabe
atraindo um ou outro fabricante que tem medo do esquerdo de cópia.  E
geralmente o suporte deles se concentra no servidor; o Linux tem mais
diferença no suporte para coisas de computador pessoal.  Embora
impressoras e acionadores de vídeo estejam fora do núcleo,
respectivamente no Cups e no X11, então para esses, que costumam
representar a maior parte dos problemas,


> Dada a maturidade das distros Linux atuais eu optaria por *BSD apenas
> se houvesse algum motivo muito forte.

Se houver a oportunidade de verificar a compatibilidade com BSDs, ou
mesmo de escolher o equipamento por sua compatibilidade, pode ser uma
boa pedida, justamente por ser mais focado no servidor, mais leve e
simples.

Talvez também por afinidade com a licença, vários desenvolvedores do
PostgreSQL preferem o BSD e dão-lhe atenção especial, mas como o
PostgreSQL está muito maduro, não espero que isso faça muita diferença
na prática; é uma razão para evitar o MS Windows, mas não o GNU/Linux.


-- 
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] Dúvida sobre sistema operacional para banco de dados PostgreSQL

[Guimarães Faria Corcete DUTRA , Leandro]

2016-08-29 22:51 GMT-03:00 Sebastian Webber :
>
> De forma genérica eu te digo: SO bom é aquele que tu (DBA) domina.

Sim, mas é um pouco mais complicado.  De maneira geral, ninguém domina
MS Windows, até por ser opaco; mesmo que o cara se ache bom de MSW,
pode valer apena aprender um sistema Posix, que se pode dominar de
fato.


> Agora, eu tenho clientes que rodam ambientes sobre FreeBSD e funciona bem.
> Assim como ambientes baseados em EL6 e EL7. Em suma, depende (do time,
> expertise, histórico, por exemplo).

O que seria EL?  RH?

Eu recomendaria ou um Debian GNU/Linux, ou um *BSD.  Mas depende de muita coisa.



-- 
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] Script para backup

[Guimarães Faria Corcete DUTRA , Leandro]

2016-08-26 16:09 GMT-03:00 Ricardo :
> From: Alexsandro Haag
> Em 26/08/2016 15:34, Ricardo escreveu:
> Na versão 9.1 eu usava o scrip abaixo para gerar o backup dos banco,
> porém depois que instalei o postgres 9.5 está dando erro de autenticação.
> Estou usando a mesma senha e usuário que uso pra autenticar no PgAdmin e
> também para conectar o banco via aplicação.
>
> Você revisou o pg_hba.conf da sua nova instalação?
> 
>
> Aparentemente o problema estava nas aspas do usuário, mudei de “postgres”
> para postgres e não deu o erro, vou fazer mais teste e dou um retorno.

Pessoal, por favor cortem rodapés, cabeçalhos, escrevam em texto
simples com as marcas de citação adequadas; se alguém escrever com
formatação, por favor convertam em texto simples antes de responder.
Fica muito ruim ler mensagens como a acima — e olhem que já limpei
rodapés e cabeçalhos!


-- 
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] RES: Chave Primaria Composta

[Guimarães Faria Corcete DUTRA , Leandro]

2016-08-26 13:40 GMT-03:00 Silfar Goulart :
>
> Eu prefiro sempre criar uma chave primaria como ID que uso para 
> relacionamentos. E uso chaves Uniques para evitar duplicidade. Para mim é a 
> melhor maneira.

Melhor por quê, se teu modelo fica mais pesado (mais índices) e mais
difícil de usar (mais junções)?

Claro que tens todo o direito de ter opiniões, ainda mais para a tua
situação específica, mas ajuda os outros se as fundamentares.



-- 
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] RES: RES: RES: Chave Primaria Composta

[Guimarães Faria Corcete DUTRA , Leandro]

2016-08-25 18:54 GMT-03:00 Vinicius Santos :
>
> Vários anos atrás vi na lista o Dutra falando sobre isso também e participei
> das discussões afim de aprender mais. Pois até o momento sempre usei ID's
> também.
>
> Tenho um produto ERP com mais ou menos 1.000 tabelas e refiz todas para
> chaves naturais. Os pontos positivos e negativos que o Adami citou também
> valeram para o meu caso.

Acho que vocês não sabem como isso me deixa feliz!



> Alguns "especialistas" "DBAs experientes" riram da minha cara, dizendo que
> isso é gambiarra. É mole?

É duro!



-- 
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] RES: RES: Chave Primaria Composta

[Guimarães Faria Corcete DUTRA , Leandro]

2016-08-25 15:31 GMT-03:00 Márcio A. Sepp :
>
>> Sim, eu entendo a "vantagem" de evitar join e você "ter" o dado já na filha 
>> ou "neta" da tabela.
>
> Gostaria de citar um exemplo prático:
[…]
> Na tabela lancamentoccu a coisa fica pior ainda, pois vc precisará também 
> criar uma referência para a tabela lote. Caso contrário vc sacrifica a 
> integridade da aplicação.
>
> Por favor, Dutra, Adami e demais...  critiquem as minhas afirmações acima?

Não vou criticar não, para mm está bom.  É isso aí.


> O que daria também pra gente fazer é criar um banco de testes e verificar 
> como ficam as coisas após uma certa carga. Daí mata isso de vez.

Testar e experimentar sempre é bom, mas o que estamos falando já foi
verificado à exaustão — além de decorrer do próprio modelo relacional
e conceitos decorrentes.


-- 
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] RES: Chave Primaria Composta

[Guimarães Faria Corcete DUTRA , Leandro]

Posso emoldurar?  ;-)


2016-08-25 15:08 GMT-03:00 Tiago José Adami <adam...@gmail.com>:
> Em 25 de agosto de 2016 14:42, Guimarães Faria Corcete DUTRA, Leandro
> <l...@dutras.org> escreveu:
>> E imagino que tanto desempenho quanto carga de máquina e de rede,
>> usabilidade e manutenção melhorem muito.
>
> Compreendi teu ponto de vista com a mensagem anterior. Aproveitei para
> lhe dar o crédito da minha implementação - considerando tuas
> incessantes reafirmações na lista para que usemos chaves naturais. Não
> é preciso dizer isso, mas, "Dutra, você sempre esteve certo" :)



-- 
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] RES: Chave Primaria Composta

[Guimarães Faria Corcete DUTRA , Leandro]

2016-08-25 14:46 GMT-03:00 Fabiano Machado Dias :
> Sim, eu entendo a "vantagem" de evitar join e você "ter" o dado já na filha
> ou "neta" da tabela.
>
> Mas assim, no que eu vi, na prática é o seguinte:
>
> 1 - A informação da chave, geralmente não é a que vc quer, então o join vai
> acontecer igual

‘Geralmente‘ é muito impreciso.  Pode significar que você economiza,
por exemplo, apenas 1% das junções ou 49% delas.  Mesmo 1% pode ser
significativo nalgumas circunstâncias, mas a verdade geralmente é bem
maior.


> 2 - Os índices ficam bem maiores

Sim, mas há menos índices.  Isso geralmente é muito importante, mais
do que haver índices menores.


> 3 - Vc tem uma redundância de informações e maior consumo de espaço

Isso geralmente não é importante, a menos que você tenha alguma
situação muito particular.


> 4 - A escrita (lembrando de modelos grandes) fica bem maior, supondo que
> você precise unir 30 tabelas cada uma com 10 campos na sua chave, pense no
> tamanha da instrução.

O tamanho da instrução é irrelevante.  Escrita, novamente, economiza a
quantidade de índices.


> O sistema em questão que eu citei anteriormente tem todos esses problemas e
> hoje é um verdadeiro elefante branco.

Sem mais informações é difícil afirmar qualquer coisa, mas eu
suspeitaria de outros problemas que não esse.  Eu chutaria falta de
normalização e de restrições declarativas de integridade (consistência
feita via código aplicativo procedural).


-- 
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] RES: Chave Primaria Composta

[Guimarães Faria Corcete DUTRA , Leandro]

2016-08-25 14:41 GMT-03:00 Tiago José Adami :
>
> Mas o uso de UK's (você se refere a UNIQUE INDEXES, certo?)

Na verdade, chaves alternativas.  Uma relação tem n chaves, onde n >=
1.  Assim, além da chave primária pode haver o outras chaves, onde o
>= 0.  É irrelevante qual das chaves se escolhe como primária, esse
conceito de chave primária está obsoleto e é vazio.



> não
> garante a integridade lógica entre as tabelas, apenas entre os
> registros de uma só tabela.

Não exatamente, a função das chaves alternativas, além de documentar o
modelo, tornando-o mais transparente (de fácil compreensão), é
justamente possibilitar a convivência de chaves naturais e artificial;
nos raros casos em que há exagero de consumo de memória por uso de
chaves naturais complexas se reproduzindo em tabelas filhas muito
maiores que as pais, pode-se ‘exportar’ a chave artificial, garantindo
a integridade referencial, enquanto as naturais seguem garantido a
unicidade.  Mas há que se lembrar que cada chave artificial é um
atributo e um índice a mais, custando não apenas memória mas também
E/S.

Creio que não é esse caso que exemplificaste abaixo, é?


> Por exemplo, eu poderia ter a tabela de
> reservas como antes:
>
> CREATE TABLE reserva (
> /* PK artificial, única */
> id_reserva SERIAL NOT NULL,
>
> /* FK tabela ITEM_RESERVA */
> id_item_reserva INTEGER NOT NULL,
>
> /* FK tabela PESSOA */
> id_pessoa INTEGER NOT NULL,
>
> (...)
> )
>
> Uma das regras do sistema é que apenas servidores do próprio campus
> possam fazer reservas dos itens do seu campus.
>
> Nesse modelo com chaves artificiais acima, mesmo que haja um índice
> único não impede de fazer uma reserva de um item do campus A para uma
> pessoa do campus B. Só se você implementar um TRIGGER que valide isso
> e retorne uma exceção, mas aí já começa a complicar demais o modelo.


-- 
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] RES: Chave Primaria Composta

[Guimarães Faria Corcete DUTRA , Leandro]

Muito obrigado por tua mensagem, Adami!  Gostei muito do exemplo e de
como o explanaste.

Só algumas pequenas observações, que nada deslustram:


2016-08-25 14:17 GMT-03:00 Tiago José Adami :
>
> E eu avalizo totalmente esta declaração. E ainda quero citar um
> exemplo do porquê chaves naturais compostas DEVEM ser utilizadas
> sempre que possível.

Eu diria que *sempre* _têm_ de ser utilizadas.  Se não for possível, é
erro de modelagem, provavelmente de compreensão ou do modelo
relacional.  Especificamente, se for necessário pode-se definir uma
chave artificial *além* das naturais.


> Como exemplo à declaração do Dutra, a tabela RESERVA_ITEM_AUTORIZACAO
> possui 7 campos em sua chave primária, todos naturais que são todos os
> campos da tabela. Ou seja, é uma tabela onde todos os campos são parte
> da chave primária, sendo uma tabela "clássica" de relacionamento N*N.

Sim, no n:n por definição todos os atributos participam da chave, que
no caso é sempre composta e única (não há chaves alternativas).

Mas referi-me a uma situação um pouco diferente: há casos em que há
dificuldades de se obter uma chave natural que realmente garanta
unicidade. Por exemplo, o RG, para as SSPs, é uma chave artificial; a
natural é nome completo, filiação, data e local de nascimento… e há
casos de duplicação dos atributos que acabo de listar, por incrível
que pareça: por exemplo, dois homens, se não me engano nascidos no
interior da BA, que tinham o mesmo nome, que nasceram no mesmo dia e
cidade, e cujos mãe e pais também tinham nomes idênticos.

Num caso desses, a saída é incorporar mais informações ao modelo.  Não
sei o que a SSP/BA fez nesse caso, nem o que as SSPs em geral fazem,
mas o óbvio seria incorporar alguma informação adicional: como
exemplos meio idiotas, só mesmo a título de exemplo, identificação da
certidão de nascimento, ou hora de nascimento, ou nomes dos avós…

Outro exemplo é uma tabela armazenando um registro de atividades
(trilha de auditoria).  Pode ser necessário colocar todos os atributos
do /log/ como chave, e no limite até incorporar um contador para o
caso em que no mesmo momento a mesmíssima mensagem apareceu várias
vezes.  Mas, geralmente, um TIMESTAMP resolve um caso desses.


> Finalizando minha "história", com exceção de um índice único e 2
> TRIGGERs para tratar horários conflitantes, toda a integridade lógica
> ficou GARANTIDA apenas pelo uso das FK's e PK's com atributos
> naturais, mesmo que com vários campos. E o número de FK's foi reduzido
> para 1 terço do que havia antes, pois a propagação das chaves
> compostas garante a integridade com a tabela "pai" de todos os níveis
> superiores.

E imagino que tanto desempenho quanto carga de máquina e de rede,
usabilidade e manutenção melhorem muito.


-- 
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] RES: Chave Primaria Composta

[Guimarães Faria Corcete DUTRA , Leandro]

2016-08-25 13:30 GMT-03:00 Márcio A. Sepp :
>
> Depende, lá como eu disse as chaves compostas foram usadas de forma errada

[…]

Márcio, quando for citar algo que alguém mais escreveu, marque para
evitar confusão.



> Vou dar uma pitada aqui, embora não sou bem um conhecedor da área. A meu ver, 
> justamente vc colocando mais atributos na chave primária deveria deixar as 
> consultas mais rápidas (se vc utilizar os campos da chave no where) e, como 
> consequencia, talvez iria utilizar mais o disco para
> armazenamento (falando a grosso modo).

Não.

Os atributos de uma chave por definição já existem no disco.  A rigor,
é a chave artificial, apesar de poder ser simples, que representa
desperdício, visto que tem de ser definida (incluindo índice) além das
chaves naturais (nunca as substituindo!), sejam estas compostas ou
simples.

A eventual economia de armazenamento seria para o caso de tabelas
‘pai’, que ‘exportariam’ apenas um atributo para as ‘filhas’.  Mas
essa economia geralmente é mais que contrabalançada por haver índice e
atributo adicional nas tabelas pais, e pelo fato de que chaves
artificiais quase sempre exigem mais junções, visto que as chaves
estrangeiras nas tabelas filhas não contém informações úteis; e pelo
fato de que geralmente as pessoas acabam não definindo chaves naturais
quando definem as artificiais, o que gera, além de inconsistências,
necessidade de tratar integridade na aplicação, o que é muito
ineficiente.


> Este assunto eu já havia levantado aqui na lista um tempo atrás e eu tbm 
> tenho dúvidas em relação a quantidade de campos na chave. Justamente nesta 
> parte mais baixa da contabilidade eu cheguei a 9 campos na chave da tabela de 
> movimentação por projeto. Tbm achei estranho isso, pois nunca havia visto uma 
> chave primária tão grande...
>
> No meu caso a chave está assim:
>   character varying(10)
>   bigint
>   smallint
>   smallint
>   smallint
>   integer
>   character(1)
>   integer
>   integer
>
> Não coloquei os nomes dos campos pq eles seguem um propósito próprio e teria 
> de colocar uma legenda pra eles e não é o propósito.

Não entendi, comentar o quê?  Sem os significados, e o resto da
estrutura e explicações, é impossível dizer qualquer coisa.  Modelagem
de dados é o tipo de coisa muito difícil de fazer remotamente
justamente pela quantidade de informações necessárias.

Em termos gerais, amiúde uma chave composta grande pode indicar falta
de normalização, e portanto ou desatenção de quem modelou, ou
desconhecimento — geralmente as pessoas entendem mal as formas
normais, e até desconhecem qualquer coisa além da 3NF.  Só para
lembrar, há sete formas normais (as 5NFs originais, a Boyce-Codd e a
temporal, esta de difícil aplicação), mas geralmente o bom senso e uma
análise atenta dá bons resultados mesmo conhecendo apenas as três
primeiras formas normais.

Mas de fato há situações em que uma chave pode chegar a cobrir todos
os atributos (naturais) de uma relação (não confundir com
relacionamento).


-- 
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] Chave Primaria Composta

[Guimarães Faria Corcete DUTRA , Leandro]

2016-08-25 11:12 GMT-03:00 Fabiano Machado Dias :
>
>> Não há limite, exceto praticidade.  E mesmo assim, às vezes deixa-se
>> de usar por ‘otimização precoce’: teme-se o efeito da propagação duma
>> chave com, digamos, quatro ou cinco atributos por tabelas filhas
>> (chaves estrangeiras), mas deixa-se de levar em conta todas as junções
>> e índices que uma chave natural economiza.
>
> Este é o ponto onde se deve ter cuidado, eu já vi um ERP onde no nível mais
> baixo da contabilidade (rateio de centro de custo) a chave primária da
> tabela tipo por volta de 15 campos!!!

Para isso que se criam chaves artificiais, que nem precisam ser
primárias.  Na verdade, o ideal é que não sejam, para que o modelo
fique mais claro e para que nunca se esqueça de definir ao menos uma
chave natural.


> Imagine como era trabalhar com uma modelagem desta!

Com um ferramental adequado, não devia ser problema algum.  Eu fazia
isso com COPYs Cobol, sem dramas.  Vi muito javeiro reclamando, e
questionava-os por que o Java seria tão inferior ao Cobol para fazer
algo tão básico.

O que tem de ver é se essa propagação de chaves compostas não seria um
problema de armazenamento ou consumo de memória.  Poderia em tese ser,
e geralmente não é, até por evitar criar campos e índices adicionais
para as chaves artificiais.

Agora, se o ferramental é ruim ou mal usado… infelizmente, uma
situação comum.  Espere problemas com usuários mais ingênuos de ORM,
por exemplo.


-- 
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] Chave Primaria Composta

[Guimarães Faria Corcete DUTRA , Leandro]

2016-08-25 11:05 GMT-03:00 Gustavo :
>
> mais um detalhe, com a chave composta
> evita um monte de triggers para ajuste de algumas informações também,
> erros de programação
> e menos manutenção

Vero.

Só um detalhe: isso não é exatamente função de chaves compostas, mas
de chaves naturais (que podem precisar ser compostas).

Na verdade, o pior problema em termos de modelagem é colocar chaves
artificiais e não colocar as chaves naturais correspondentes.  Qual é
primária ou não, não tem a mesma importância para para consistência
(integridade)  — embora seja importante para evitar junções, por
exemplo.


-- 
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] Chave Primaria Composta

[Guimarães Faria Corcete DUTRA , Leandro]

2016-08-25 10:49 GMT-03:00 Gustavo :
>
> Razão, seria as lendas urbanas que sempre eu via sobre isso...

Boa definição.


> agora você me dizendo que é uma otima ideia  ja até pensei em uma chave 
> primaria com 3 campos

Não há limite, exceto praticidade.  E mesmo assim, às vezes deixa-se
de usar por ‘otimização precoce’: teme-se o efeito da propagação duma
chave com, digamos, quatro ou cinco atributos por tabelas filhas
(chaves estrangeiras), mas deixa-se de levar em conta todas as junções
e índices que uma chave natural economiza.


> vamos analisar da seguinte maneira. se não fosse uma boa prática não teria 
> essa opção para ser usada no banco de dados...

Infelizmente essa lógica nem sempre se aplica.  Por exemplo, herança
geralmente não é boa idéia, pelo menos não no modelo lógico; no modelo
físico, foi útil para gambiarrar particionamento de tabelas.


-- 
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] Configurações Servidor Desenvolvimento Postgres

[Guimarães Faria Corcete DUTRA , Leandro]

2016-08-25 10:25 GMT-03:00 Leonardo Coleraus :
>
> qual a melhor configuração pra fazer no postgres.conf, do servidor de 
> DESENVOLVIMENTO pra ter um bom ambiente de teste, pois no meu Servidor de 
> Produção esse balancete demora em torno de 1 hora pra fazer

Tudo depende.  Tem de ver que consultas tomam mais tempo, qual a
estrutura envolvida, estatísticas, configurações atuais tanto do SGBD
quanto de SO e servidor, versões de programas 

Dica: pg_tune.


-- 
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] Chave Primaria Composta

[Guimarães Faria Corcete DUTRA , Leandro]

2016-08-25 10:22 GMT-03:00 Gustavo :
>
> eu nunca utilizei uma chave primaria com 2 campos em 12 anos

Alguma razão para isso?


> a pergunta é, seria uma boa pratica utilizar chave primaria composta

Ótima!


> eu terei problemas com isso ?

Só em situações-limite, muito específicas mesmo.  Ou seja, certeza
quase absoluta que não.


-- 
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] alterar encoding durante uma VIEW

[Guimarães Faria Corcete DUTRA , Leandro]

2016-08-10 13:08 GMT-03:00 Flavio Henrique Araque Gurgel :
>
> O Op pode criar um usuário separado para seu Excel, digamos usr_excel, e
> mudar o client encoding dele :
> ALTER USER usr_excel SET client_encoding = 'LATIN1';
>
> Conectar a partir do Excel com esse usuário específico, deve resolver.

Provável.  Nem sei por que respondo, esperar o Gurgel responder é sempre melhor.


-- 
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] alterar encoding durante uma VIEW

[Guimarães Faria Corcete DUTRA , Leandro]

2016-08-10 10:22 GMT-03:00 Luiz Henrique :
>
> Tenho a seguinte situação : meu postgres 9.1 LINUX CENTOS tem encoding UTF8.

Perfeito, é o ideal.


> Ao criar uma view para ser utilizada no MS Office (tabela dinâmica excel) dá
> erro de codificação (erro na tabela dinâmica excel ao utilizar a view).

Sem mais detalhes?  E quais as configurações do MS Excel?  Que versão
dele?  Ele não tem como informar a codificação esperada da sessão?
Experimentou isso com o LibreOffice?


> Até
> onde eu entendi é necessário alterar o encoding para WIN1252 ou LATIN1 (por
> exemplo).

Por exemplo não, tem de ser um específico.  Até há um grau de
compatibilidade entre algumas codificações, mas para evitar erros tem
de usar ou o mesmo, ou informar uma conversão viável.  Por isso o
UTF-8 (ou algum outro Unicode) é o ideal, dá para converter para
qualquer coisa.


> Dúvida : como eu posso , em tempo de execução da VIEW, alterar o
> ENCODING ? É possivel ?

Se a sessão do programa aplicativo (ou do usuário, se interativo)
informar a codificação esperada, haverá conversão automática a partir
do Unicode.  Não sei como é isso a partir do MS Excel.


-- 
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] Porque o UBER trocou o PostgreSQL para o MySQL

[Guimarães Faria Corcete DUTRA , Leandro]

2016-08-02 18:20 GMT-03:00 Flavio Henrique Araque Gurgel :
>
> Homem de verdade é aquele que toma porrada na lista internacional e passa
> link do artigo do cara que lhe bateu.

Dessa não fiquei sabendo!


> O problema é que todo mundo que trabalha em TI adora o Uber, aí o barulho é
> generalizado demais.

Verdade.  A questão é saber se haverá alternativas melhor geridas.
Esse artigo dá medo se conseguirão escalar.


> Ou, a velha frase do marketing, um cliente satisfeito pode te trazer mais um
> ou dois, enquanto um cliente insatisfeito te leva dez embora. Aí o Uber fez
> a parte delas na meleca toda.

E parece que com um tom autojustificativo: ‘fizemos porcaria, aqui
está nossa desculpa esfarrapada.  Não nos culpe pela nossa ignorância,
nem reclame de falarmos mal de quem é melhor que nós e sem fundamento
algum’.


> PS.: uma cerveja com um amigo ontem me fez perder esse fantástico webcast ao
> vivo. Muito obrigado aos apresentadores, ficou muito show.

Achei que aí na Gália o negócio era vinho!… ;-)


-- 
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] Porque o UBER trocou o PostgreSQL para o MySQL

[Guimarães Faria Corcete DUTRA , Leandro]

2016-08-02 17:07 GMT-03:00 Sebastian Webber :
>
> Interessante é que uma empresa com mais dados que eles (20PB) saiu do oracle
> pro postgres e nimguém fez barulho. :)
>
> https://www.youtube.com/watch?v=-SS4R1sFH3c=PLuJmmKtsV1dNE5y1gu1xpbIl3M2b7AW4D

Creio que um artigo técnico com aparência de ser bem-feito tenha mais
repercussão que um vídeo.  Ademais, creio que a repercussão também
tenha a ver com as expectativas das pessoas: por fatores culturais
(para não falar do clima de fim de civilização), a ‘síndrome do
desenvolvedor’, de tentar resolver tudo com código aplicativo
ignorando boas práticas, conceitos sólidos e o aprendizado histórico,
ataca sempre e dá ampla divulgação ao que confirma as pessoas em sua
ignorância.

Ou vai ver que sou só eu mesmo que estou sem paciência… isso é que dá
ficar meio esgotado.


-- 
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] Porque o UBER trocou o PostgreSQL para o MySQL

[Guimarães Faria Corcete DUTRA , Leandro]

2016-08-02 16:41 GMT-03:00 Fábio Telles Rodriguez :
>
> 2016-08-01 11:27 GMT-03:00 Flavio Henrique Araque Gurgel :
>>
>> > O melhor resumo até agora me parece ser
>> > http://use-the-index-luke.com/blog/2016-07-29/on-ubers-choice-of-databases
>
> Esse também ficou muito bom:
> http://blog.2ndquadrant.com/thoughts-on-ubers-list-of-postgres-limitations/

De fato.

Resumo da ópera: contrataram gente incompetente, gastaram muitos
recursos para fazer uma porcaria funcionar em vez de aprender a usar o
que já tinham.  Claro, tudo baseado em escolhas arquitetônicas
absurdas.

O de quase sempre, quando se usa MySQL ou NoSQL.  A exceção são os
casos em que esses produtos são bem usados.


-- 
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] CPU em 100%

[Guimarães Faria Corcete DUTRA , Leandro]

2016-06-15 8:55 GMT-03:00 Tales Costa <talesroda...@gmail.com>:
> Em 9 de junho de 2016 12:33, Guimarães Faria Corcete DUTRA, Leandro
> <l...@dutras.org> escreveu:
>>
>> Não deixas o autovaccuum?
>
> Deixei um tempo desativado para alguns testes, mas costumo deixar ele ativo.

Bom.


> A alguma vantagem e executar manualmente e deixar o autovacuum ativo ?

Pelo contrário.  O recomendado é deixar ativo e só executar
manualmente em caso de necessidade clara, em situações excepcionais.


-- 
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] Instalação SEM without-zlib

[Guimarães Faria Corcete DUTRA , Leandro]

2016-06-14 10:33 GMT-03:00 Marcio Meneguzzi :
>
> Após ter instalado o PostgreSQL usando a opção --without-zlib, há
> possibilidade de inserir a função zlib sem necessidade de uma nova
> instalação?

O Flávio já explicou que sim.  Mas eu recomendaria instalar um pacote
precompilado, que evitaria essas questões, a menos que você tenha uma
necessidade real e comprovada de compilar.  O fato de que você
compilou com menos do que ia precisar parece indicar que talvez essa
necessidade não exista.


-- 
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] [Reinstalar Postgres ] - versão 9.0

[Guimarães Faria Corcete DUTRA , Leandro]

2016-06-14 11:05 GMT-03:00 Daniel Luiz da Silva :
> Fiz uma instalação do Postgres 9.0.5

Por que tão arcaica?  Não é mais suportada há anos, terias de estar
pelo menos na 9.1.22.  Atualize imediatamente para 9.0.23, e comece
imediatamente a planejar a atualização para pelo menos 9.1.22,
preferencialmente 9.5.3.


> através de pacote compilado

Queres dizer que o compilaste, em vez de usar um compilado?  Por que
não usaste um pacote precompilado?  Evitaria essas questão.
Geralmente os benefícios de compilar não compensam os riscos.


> Hoje necessita colocar a replicação do Bucardo para funcionar,
> porém, necessito reinstalar o Postgres com a opção --with-perl, além dos
> outros pacotes para rodar o Bucardo. Minha dúvida é com relação o risco para
> realizar essa operação, o Postgres reinstala somente a lib faltante ou faz a
> reinstalação completa?

Eu recomendaria reinstalar por pacote precompilado, para não correr os
riscos inerentes à compilação, inclusive esse de faltar algo.


> Sobre o risco dessa operação, é alto? ou seja, existe
> uma chance grande de ocorrer algum problema?

Que problema?  Desde que você se mantenha na 9.0 — o recomendado seria
a última, 9.0.23, que já não é suportada mas corrige vários problemas
da 9.0.5 —, ou siga os procedimentos para atualizar sua base para algo
mais recente, só mesmo o risco de erro humano.  O risco de continuar
na 9.0.5 é maior que o de atualizar para a 9.0.23.  Aliás, o risco de
continuar na 9.0, mesmo que 9.0.23, é maior que o de atualizar para
uma versão suportada, como a 9.1.22 ou a 9.5.3.



-- 
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] Problemas com ‘alternativas’ ao modelo relacional

[Guimarães Faria Corcete DUTRA , Leandro]

2016-06-09 23:32 GMT-03:00 Tiago José Adami :
>
> Na verdade a maioria que conheço critica sem nunca ter usado e
> defendem o modelo relacional/SQL para tudo. Radicais "SQLtremistas".

Isso existe.  Mas veja que você está confundindo o modelo relacional
com SQL; um é um conceito, outro uma implementação.  O que me parece
que talvez alguns desses extremistas que acusam talvez tenham uma
melhor compreensão das questões que a tua.

Tentando explicar melhor: o SQL tem limitações, sim.  Mas o modelo
relacional, não: o SQL tem várias restrições em relação ao modelo
relacional, que é capaz de faze tudo o que se pode fazer com dados,
por ser a única teoria de dados validada até hoje — na verdade, tem a
dos grafos também, mas é muito mais limitada e complexa.

Como já se disse à exaustão nesta lista e noutras, o que o NoSQL
contribui é com técnicas de armazenagem e (ou) recuperação que,
tipicamente, uma vez validadas, o PostgreSQL (e por vezes algum outro
SGBD SQL) pode incorporar.  Talvez no final das contas as limitações
inerentes ao SQL se tornem suficientemente importantes, e o
conhecimento sobre o modelo relacional suficientemente amplo, para que
abandonemos o SQL em favor de algo puramente relacional, o que
facilitará ainda mais a incoroporação das técnicas de armazenagem e
recuperação gestadas fora do mundo SQL.

Pelo jeito, está na hora de lançar novamente meu desafio: quem critica
o modelo relacional geralmente não o compreendeu.  E no Brasil há
pouquíssimas pessoas que o aprendem na escola, porque geralmente ou os
próprios professores não aprenderam, ou foram corrompidos pelas
vantagen$ de se trabalhar com os fornecedores de sistemas
proprietários SQL, infelzimente.  Portanto, vós que defendeis o NoSQL,
desafio-vos: por favor, definam o que é o modelo relacional.

E quem tiver tentado responder, acertado ou não, recomendo ler o
artigo do Codd em que ele o delineia
, para ver a
que situação ele respondeu ao criá-lo.  Quase meio século atrás.

Por outro lado, minha crítica ao NoSQL é que, ao propagandear suas
técnicas de armazenagem e recuperação, esquece-se de tudo o que o
modelo relacional resolveu, como fica óbvio no caso em tela, e
reinventa-se a roda mal e porcamente.  Ganha-se muito mais ao
usarem-se essas técnicas no PostgreSQL, como demonstra uma simples
busca .  Dependendo da
situação, até o @#%$$%!#@$% do MySQL supera o NoSQL
!

Ou seja, trocando em miúdos: NoSQL é útil para quem tem uma
necessidade que o PostgreSQL _ainda_ não cobre.  Como foi o caso de
grandes provedores de serviço, mas dificilmente é o de alguém desta
lista.  E mesmo para esses, a tendência é regularizar com o PostgreSQL
ou algum outro SQL.  Só para dar mais um exemplo, o Google
praticamente inaugurou essa moda com o famoso /map-reduce/; hoje, usa
um serviço SQL sobre uma base (quase-)relacional, o F1 e o Spanner.  O
Yahoo fez isso antes, com o Himalaia, baseado no PostgreSQL.


-- 
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] Vagas pra ETL e BI

[Guimarães Faria Corcete DUTRA , Leandro]

2016-06-09 14:15 GMT-03:00 Rebert Tomaz Aquino :
> ok, desconsiderem a vaga então.

Pode ser que haja interessados.  Mas a netiqueta manda que você
explique em que as vagas seria relevantes para esta lista.  DBA?  AD?
Programador SQL ou alguma PL de PostgreSQL?


> desculpem

Não tem problema, vivendo e aprendendo.


-- 
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] Vagas pra ETL e BI

[Guimarães Faria Corcete DUTRA , Leandro]

2016-06-09 14:09 GMT-03:00 Rebert Tomaz Aquino :
> isso não e SPAN.. apenas divulguei 2 vagas de consultoria, aqui não pode
> colocar vagas?? se não.. desculpe

Veja, você mandou uma oferta genérica para esta lista de discussões,
sem nem explicar em que isso seria relevante para esta comunidade.
Isso é sim /spam/ (não SPAN, que significa outra coisa e não se grafa
em maiúsculas).


-- 
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] Problemas com ‘alternativas’ ao modelo relacional

[Guimarães Faria Corcete DUTRA , Leandro]

2016-06-09 12:47 GMT-03:00 Fabrízio de Royes Mello <fabri...@timbira.com.br>:
> On 08-06-2016 14:55, Guimarães Faria Corcete DUTRA, Leandro wrote:
>> https://engineering.meteor.com/mongodb-queries-dont-always-return-all-matching-documents-654b6594a827#.phpzbdxtf
>
> IMHO o problema descrito tem mais a ver com a forma como a ferramenta
> implementa controle de concorrência do que o modelo de dados em si.

É verdade, a rigor.  Mas veja que ‘não há almoços grátis’; quando
alguém promete algo melhor que o relacional, geralmente o que fez foi
gambiarra mesmo.


-- 
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] CPU em 100%

[Guimarães Faria Corcete DUTRA , Leandro]

2016-06-09 9:12 GMT-03:00 Tales Costa :
> Em relação ao vacuum, executo 1 vez por semana (analise e limpeza), porém
> surtiu efeito no uso de CPU.

Não deixas o autovaccuum?

Procure cortar o texto ao qual não responde, como saudações e assinaturas.


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