Re: [pgbr-geral] Slides - PGBR 2017

[Fabiano Machado Dias]

Não sabia! Obrigado pelo retorno.

Abs.
Fabiano

Em 22 de setembro de 2017 11:15, Sebastian Webber <sebast...@swebber.me>
escreveu:

>
>
> Em sex, 22 de set de 2017 às 11:12, Fabiano Machado Dias <
> fabi...@wolaksistemas.com.br> escreveu:
>
>> Queria muito ver a palestra do Emerson Engroff, PG em Memória,
>> infelizmente não consegui ir pela manhã no evento.
>>
>>
> Ele acabou não vindo e usamos a sala pra extender outra palestra.
>
> ___
> pgbr-geral mailing list
> pgbr-geral@listas.postgresql.org.br
> https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
>
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Slides - PGBR 2017

[Fabiano Machado Dias]

Queria muito ver a palestra do Emerson Engroff, PG em Memória, infelizmente
não consegui ir pela manhã no evento.

Abs.
Fabiano

Em 22 de setembro de 2017 10:53, Sebastian Webber <sebast...@swebber.me>
escreveu:

>
>
> Em sex, 22 de set de 2017 às 10:51, Fabiano Machado Dias <
> fabi...@wolaksistemas.com.br> escreveu:
>
>> Bom dia,
>>
>> Alguém sabe quando serão disponibilizados os slides das palestras do PGBR?
>>
>
> E ai Fabiano, tudo bem?
>
> Alguns deles já estão no site.
>
> Estou atualizando os mesmos conforme o pessoal vai me mandando.
>
> --
> Sebastian Webber
> http://swebber.me
>
> ___
> pgbr-geral mailing list
> pgbr-geral@listas.postgresql.org.br
> https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
>
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

[pgbr-geral] Slides - PGBR 2017

[Fabiano Machado Dias]

Bom dia,

Alguém sabe quando serão disponibilizados os slides das palestras do PGBR?

Att,
Fabiano Machado Dias
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Perder Dados

[Fabiano Machado Dias]

Você não está gravando uma nota por cima de outra? Como seu "log" aponta a
gravação, pode ser que em algum determinado momento você esteja pegando
algum dado sujo e sobrescrevendo a nota que já tinha sido emitida, por isso
seu "log" não acusa erro.

Já vi algo parecido acontecer com chaves seriais controladas pela camada de
persistência e tb por "sujeira" em variáveis de controle.

De qualquer forma, faça como já foi recomendado, ligue os logs do banco e
confie neles, se o seu "log" não está apontando o erro é pq ele tb não é
confiável.

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

[Fabiano Machado Dias]

Dá uma olhada no DBSchema, ele gera o esquema em HTML5, já usei ele e
gostei do resultado.

Att,
Fabiano

Em 14 de setembro de 2016 10:42, Danilo Silva 
escreveu:

> Pessoal,
>
> 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.
>
> []s
> Danilo
>
> ___
> pgbr-geral mailing list
> pgbr-geral@listas.postgresql.org.br
> https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
>
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] RES: Chave Primaria Composta

[Fabiano Machado Dias]

> > 1 - A informação da chave, geralmente não é a que vc quer, então o join
> vai
> > acontecer igual
>
> Discordo. Se suas chaves naturais estão bem definidas, na grande
> maioria das vezes é suficiente. Por exemplo: a consulta mais
> recorrente sobre a tabela RESERVA é listar todas as reservas do campus
> 'DV' e do usuário logado no sistema pelo campo matricula_usuario. Não
> preciso de JOIN para fazer isso com o "modelo natural".
>
> Esta declaração só é verdadeira no caso de relatórios que busquem mais
> informações, mas neste caso você pode eliminar o JOIN com tabelas
> intermediárias, tornando o modelo com chaves naturais ainda mais
> eficiente.
>
>
Quando vc varre uma tabela de itens de uma nota, vc está buscando dados do
item né? E a programação de entrega desse item? Não está em outra tabela
ainda? Entende o que quero dizer?



> > 2 - Os índices ficam bem maiores
>
> Apenas "O" índice da chave primária fica maior. Você poderá ter
> índices auxiliares que terão o mesmo tamanho.
>

Mesmo exemplo acima. Nota/item/programacao_entrega - vejo o tamanho desses
índices em um caso real.



>
> > 3 - Vc tem uma redundância de informações e maior consumo de espaço
>
> Isto é fato. Na migração do banco o crescimento foi na ordem de cerca
> de 20% com os testes que fiz. Contrabalanceando, o desempenho das
> consultas ficou muito mais rápido.
>

Não sei o tamanho das bases que trabalha, mas pra mim é um problema em
vários clientes atualmente (bases na case de alguns teras)



>
> > 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.
> >
>
> A escrita ou a união em um SQL?  Acredito que exista, sim, uma carga
> adicional na escrita, mas isso é irrelevante em relação aos benefícios
> obtidos, principalmente no desempenho das consultas.
>

Olha, hoje em dia eu vejo cada vez menos desenvolvedores com conhecimentos
de SQL, quando eu mostro uma consulta com vários join's vários arrepiam os
cabelos, mas sim é irrelevante quando se sabe o que está fazendo.


>
> Sobre "unir 30 tabelas cada uma com 10 campos na sua chave": Para isto
> existe o NATURAL JOIN. E repito, com o modelo feito com propagação de
> chaves naturais, pela minha experiência a necessidade de usar tabelas
> intermediárias diminui muito. Dificilmente uma consulta mais complexa
> do sistema hoje faz JOIN com mais de 2 tabelas, sendo que antes eram
> necessárias pelo menos 3 tabelas em JOIN em *todas* as consultas SQL.
>

Não estou sendo contra as chaves naturais, mas acho que vc pode obter o
melhor sabendo usar os 2 cenários


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

Re: [pgbr-geral] RES: Chave Primaria Composta

[Fabiano Machado Dias]

> intermediárias diminui muito. Dificilmente uma consulta mais complexa
> do sistema hoje faz JOIN com mais de 2 tabelas, sendo que antes eram
> necessárias pelo menos 3 tabelas em JOIN em *todas* as consultas SQL.
>
>
>

Uma pena eu não poder expor algumas consultas que usamos aqui, não sei se
já trabalhaste com SPED / Bloco K e outras obrigações fiscais, praticamente
vem informação desde a produção até o lançamento contábil do documento, os
SQL's são gigantescos e deixam qualquer DBA de cabelo em pé.
___
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

[Fabiano Machado Dias]

Isso aí, chave primária é só uma chave, não precisa ser a "sua" principal
chave no modelo. No caso dos ORM's que gostam de usar os famigerados
"ID's", deixe que eles usem isso, vc usa as suas chaves e doutrina os seus
desenvolvedores.

Em 25 de agosto de 2016 14:54, Guimarães Faria Corcete DUTRA, Leandro <
l...@dutras.org> escreveu:

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

[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
2 - Os índices ficam bem maiores
3 - Vc tem uma redundância de informações e maior consumo de espaço
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 sistema em questão que eu citei anteriormente tem todos esses problemas e
hoje é um verdadeiro elefante branco.



Em 25 de agosto de 2016 14:41, Tiago José Adami <adam...@gmail.com>
escreveu:

> Em 25 de agosto de 2016 14:29, Fabiano Machado Dias
> <fabi...@wolaksistemas.com.br> escreveu:
> > Legal, você poderia usar UK's e ainda assim manter a suas chaves
> > artificiais, muitas vezes a preocupação com a chave primária faz com que
> as
> > pessoas esqueçam que podemos ter N UK's para manter a integridade nos
> > trilhos e no banco!
> >
> > Hoje tenho diversos projetos onde o uso de ORM é constante, para conviver
> > com ele faço isso, o fato é que tabela sem chave natural é o inferno de
> > qualquer modelo.
>
> Mas o uso de UK's (você se refere a UNIQUE INDEXES, certo?) não
> garante a integridade lógica entre as tabelas, apenas entre os
> registros de uma só tabela. 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.
>
> Outra vantagem das chaves naturais é saber pela tabela "filha" quem
> são os "pais". Neste exemplo com chaves artificiais, eu precisava
> fazer JOIN com mais 3 tabelas para saber qual o campus.
>
> TIAGO J. ADAMI
> ___
> pgbr-geral mailing list
> pgbr-geral@listas.postgresql.org.br
> https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
>
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] RES: Chave Primaria Composta

[Fabiano Machado Dias]

Legal, você poderia usar UK's e ainda assim manter a suas chaves
artificiais, muitas vezes a preocupação com a chave primária faz com que as
pessoas esqueçam que podemos ter N UK's para manter a integridade nos
trilhos e no banco!

Hoje tenho diversos projetos onde o uso de ORM é constante, para conviver
com ele faço isso, o fato é que tabela sem chave natural é o inferno de
qualquer modelo.



Em 25 de agosto de 2016 14:22, Tiago José Adami 
escreveu:

> Em 25 de agosto de 2016 14:17, Tiago José Adami 
> escreveu:
> > CREATE TABLE reserva_item_autorizacao (
>
> Corrigindo os comentários
>
> Tabela RESERVA_ITEM só possui 2 FKs:
> - codigo_patrimonio é FK da tabela ITEM_RESERVA;
> - demais campos são FK da tabela RESERVA
>
> Tabela RESERVA_ITEM_AUTORIZACAO só possui 2 FKs:
> - matricula_autorizacao é FK da tabela PESSOA;
> - demais campos são FK da tabela RESERVA_ITEM
>
> TIAGO J. ADAMI
> ___
> pgbr-geral mailing list
> pgbr-geral@listas.postgresql.org.br
> https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
>
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Chave Primaria Composta

[Fabiano Machado Dias]

Depende, lá como eu disse as chaves compostas foram usadas de forma errada,
era uma estrutura de grupo, empresa, filial, unidade +
chave_negocio_tabela, então de cara qualquer PK já tinha no mínimo 5 campos!

Sem contas outras gambiarras que não vem ao caso aqui.



Em 25 de agosto de 2016 11:33, Gustavo <gustavo.14042...@gmail.com>
escreveu:

>  (lembro que eram quase 4 mil tabelas), ouch !
>
> o meu só tem 1.000 tabelas...   será que terei problemas com performance
> 
> ᐧ
>
> Em 25 de agosto de 2016 11:26, Fabiano Machado Dias <
> fabi...@wolaksistemas.com.br> escreveu:
>
>> O maior problema era o inchaço do banco (lembro que eram quase 4 mil
>> tabelas), além da escrita de consultas, um join básico ficava gigante,
>> imagina então algo maior como um SPED!
>>
>> Não tenho mais contato com esse sistema, mas sei que até hoje sofre com
>> problemas de performance nos clientes que usam.
>>
>>
>>
>> Em 25 de agosto de 2016 11:20, Guimarães Faria Corcete DUTRA, Leandro <
>> l...@dutras.org> escreveu:
>>
>>> 2016-08-25 11:12 GMT-03:00 Fabiano Machado Dias <
>>> fabi...@wolaksistemas.com.br>:
>>> >
>>> >> 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
>>>
>>
>>
>> ___
>> pgbr-geral mailing list
>> pgbr-geral@listas.postgresql.org.br
>> https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
>>
>
>
> ___
> pgbr-geral mailing list
> pgbr-geral@listas.postgresql.org.br
> https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
>
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Chave Primaria Composta

[Fabiano Machado Dias]

O maior problema era o inchaço do banco (lembro que eram quase 4 mil
tabelas), além da escrita de consultas, um join básico ficava gigante,
imagina então algo maior como um SPED!

Não tenho mais contato com esse sistema, mas sei que até hoje sofre com
problemas de performance nos clientes que usam.



Em 25 de agosto de 2016 11:20, Guimarães Faria Corcete DUTRA, Leandro <
l...@dutras.org> escreveu:

> 2016-08-25 11:12 GMT-03:00 Fabiano Machado Dias <
> fabi...@wolaksistemas.com.br>:
> >
> >> 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
>
___
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

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

Imagine como era trabalhar com uma modelagem desta!

Att,
Fabiano Machado Dias
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] VACCUM FULL linhas deletadas não sendo apagadas

[Fabiano Machado Dias]

>From manual:

*VACUUM FULL rewrites the entire contents of the table into a new disk file
with no extra space, allowing unused space to be returned to the operating
system. This form is much slower and requires an exclusive lock on each
table while it is being processed.*

Link: http://www.postgresql.org/docs/current/static/sql-vacuum.html
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] oracle_fdw - Windows

[Fabiano Machado Dias]

Achei o problema, o client que estava na máquina era 32 bits, baixei o
instant_client 64, apontei o ORACLE_HOME pra ele e foi, oracle_fdw
instalado!

Abraço,
Fabiano Machado Dias

Em 28 de março de 2016 12:31, Jaírton TiNhO <jairto...@gmail.com> escreveu:

> Já tentou registrar essa DLL no Windows?
>
> ___
> pgbr-geral mailing list
> pgbr-geral@listas.postgresql.org.br
> https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
>
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

[pgbr-geral] oracle_fdw - Windows

[Fabiano Machado Dias]

Bom dia pessoal,

Estou tentando instalar o oracle_fdw em um servidor Windows Server 2012 -
64 bits

A versão do PostgreSQL é 9.5.1 - 64 bits

Fiz, o download do FDW no site oficial, coloquei os arquivos nas
respectivas pastas, o client do Oracle está instalado e as variáveis
ORACLE_HOME e TNS_ADMIN estão setadas.

Porém ao rodar o comando:

CREATE EXTENSION oracle_fdw;

Recebo o seguinte erro:

"ERROR:  could not load library "C:/Program
Files/PostgreSQL/9.5/lib/oracle_fdw.dll": %1 is not a valid Win32
application."

Já usei o oracle_fdw diversas vezes, mas sempre em Linux e nunca tive
maiores problemas.

Dei uma olhada nas permissões também, a princípio está tudo liberado.

Também já tentei usar a DLL do FDW tanto na versão 32 quanto 64 e nada.

Alguém tem alguma luz?

Abraço,
Fabiano Machado Dias
___
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 na replicação Postgres

[Fabiano Machado Dias]

Valeu pessoal consegui resolver refazendo todo o processo e parando as
> rotinas que escreviam no banco durante o basebackup
>
>

Você também poderia ter feito o arquivamento do WAL, daí bastaria
configurar a recovery.conf para ler este mesmo local, assim mesmo que não o
wal_keep_segments estivesse baixo conseguiria buscar o histórico e concluir
a sincronização.

Att,
Fabiano Machado Dias
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

[pgbr-geral] Palestra - Migração Oracle x PostgreSQL - PGBR 2015

[Fabiano Machado Dias]

Boa noite pessoal,

Compartilhei a minha palestra no Slideshare[1], devido ao problema que
ocorreu no dia da apresentação, postei um vídeo no Youtube[2] onde
demonstro uma migração de Oracle XE para PostgreSQL usando o Ora2pg.

Peço desculpas pelo áudio que ficou um pouco baixo e pela demora em
disponibilizar os slides.

[1]
http://pt.slideshare.net/mdfabiano/migrao-de-oracle-para-postgresql-indo-alm-do-sgbd

[2] https://www.youtube.com/watch?v=-DF5FT__OKw

Um grande abraço,
Fabiano Machado Dias
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

[pgbr-geral] Fotos - PGBR 2015

[Fabiano Machado Dias]

Boa tarde pessoal,

Segue as fotos do evento

https://flic.kr/s/aHskowKYsD

Abraço,
Fabiano Machado Dias
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Album de fotos do pgbr2015

[Fabiano Machado Dias]

Boa tarde pessoal,

Fiz upload das minhas fotos, desculpe pela demora só consegui um tempo hoje.

Abraço,
Fabiano Machado Dias
___
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: Segurança dos dados

[Fabiano Machado Dias]

Existe o EDB*Wrap da Enterprise DB, claro que é outra história, afinal não
é PostgreSQL da comunidade, mas pode interessar a alguém.

http://www.enterprisedb.com/docs/en/9.3/eeguide/Postgres_Plus_Enterprise_Edition_Guide-35.htm

Att,
Fabiano Machado Dias
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] 10 desvantagens do PostgreSQL em relação ao Oracle

[Fabiano Machado Dias]

Particionamento, no Oracle é bem mais simples.
Em 10/01/2015 06:19, Fábio Telles Rodriguez fabio.tel...@gmail.com
escreveu:

 Bom, publiquei minha lista... vamos ver o que acontece agora:

 http://savepoint.blog.br/oracle-x-postgresql-parte-ii-vantagens-do-oracle/

 Agradeço se deixarem seus comentários no próprio blog, ajuda para quem for
 consultar lá futuramente.

 Agora só falta a 3ª parte, as vantagens do PostgreSQL, claro!!!

 Em 9 de janeiro de 2015 22:45, Marcelo Florindo marceloflori...@gmail.com
  escreveu:

 Douglas,
 O ambiente de administração do oracle é apex……a Oracle está investindo
 pesadamente nele.


 Abraço,

 Marcelo

 Em 09/01/2015, à(s) 20:38, Douglas Fabiano Specht 
 douglasfabi...@gmail.com escreveu:



 Em 9 de janeiro de 2015 17:33, Marcelo Florindo 
 marceloflori...@gmail.com escreveu:

 Dentro deste comparativo, não só ao oracle banco, mas um item que
 gostaria de ver no postgres é o apex (apex.oracle.com).

 Já imaginaram um ambiente de desenvolvimento utilizando o postgres de
 cabo a rabo?? Seria muito show!

 Abraço a todos,

 Marcelo

 Em 09/01/2015, à(s) 17:10, Dadilton Melo dadil...@gmail.com escreveu:

 Olá pessoal,

 Me metendo nessa conversa de gente grande, não sei se é exatamente uma
 desvantagem, mas o fato de o postgresql não utilizar mais que um core de
 cpu por consulta (Query) pode se revelar um problema em alguns ambientes.
 Este assunto já é discutido em
 http://www.postgresql.org/message-id/48fcd67d.4070...@sun.com , e pelo
 que parece, estão tentando implementar isso no PostgreSQL.

 Já vi que houve alguma discussão aqui sobre isso e já falaram que as
 consultas paralelas do ORACLE servem como gambiarra para resolver o
 problema de performance de consultas mal feitas. Mas a verdade é que, em
 alguns casos, isso realmente pode se mostrar uma boa forma de melhorar o
 desempenho do sistema. Até mesmo porque o DBA, infelizmente, não pode
 contar muito com o conhecimento do desenvolvedor ao fazer suas consultas na
 base de dados. Além do mais, as consultas paralelas não funcionam sempre,
 mas só em alguns casos, por exemplo, quando é necessário fazer um full
 table scan, ou quando numa mesma consulta existem blocos que, separados,
 podem trazem resultados independentes, etc. Sem falar que consomem mais
 recursos de hardware. Além do mais, a ORACLE deu um jeito de permitir
 gambiarra, e permite a execução do seguinte comando ALTER SESSION FORCE
 PARALLEL QUERY. para forçar o uso de vários cores de CPU. Tem mais
 alguns detalhes aqui http://www.dba-oracle.com/art_builder_opq_cpu.htm

 Corrijam-me, em caso de eu haver falado besteira, por favor :)

 Já me falaram até que o fato de o ORACLE permitir HINTs (para ignorar
 obrigar o uso de índices, ou consultas paralelas - coisa que o PostgreSQL
 não tem) já indicam que o otimizador de consultas dele pode não ser lá
 muito eficiente.

 Mas aí já é outro papo, rs.

 Abraços.

 Em 9 de janeiro de 2015 16:06, Fabiano Machado Dias 
 fabi...@wolaksistemas.com.br escreveu:

 Postgres 9.4 : Aggregate FILTER clause (Uma mão na roda!)

 Abraço,
 Fabiano Machado Dias




 Em 9 de janeiro de 2015 15:58, Cleysson Lima listapostgre...@gmail.com
  escreveu:

 Hehehe concordo com o Flávio :)

 Tópico
 - Certificação



 Em 9 de janeiro de 2015 12:13, Flavio Henrique Araque Gurgel 
 fha...@gmail.com escreveu:

 Eu sei, eu sei... mas existem né? Nem tudo é perfeito AINDA.

 Comecei a escrever uma trilogia comparando o Oracle com o PostgreSQL
 e
 queria saber na opinião de vocês onde vocês acham que o Oracle leva
 vantagem sobre o PostgreSQL.

 Sem flames, por favor!!!


 Troll pode?
 Vantagem Oracle:
 Larry Ellison é bilionário.

 Desvantagem PostgreSQL:
 Tom Lane bebe cerveja na PgCon.

 Mas eu acho que o segundo se diverte mais :)
 ___
 pgbr-geral mailing list
 pgbr-geral@listas.postgresql.org.br
 https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral



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



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




 --

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



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


 Na MINHA opinião o ambiente de administração do oracle é muito show de
 bola..
 Infelizmente no postgresql é muito na unha.

 --

 Douglas Fabiano Specht
  ___
 pgbr-geral mailing list
 pgbr-geral@listas.postgresql.org.br
 https

Re: [pgbr-geral] 10 desvantagens do PostgreSQL em relação ao Oracle

[Fabiano Machado Dias]

Postgres 9.4 : Aggregate FILTER clause (Uma mão na roda!)

Abraço,
Fabiano Machado Dias




Em 9 de janeiro de 2015 15:58, Cleysson Lima listapostgre...@gmail.com
escreveu:

 Hehehe concordo com o Flávio :)

 Tópico
 - Certificação



 Em 9 de janeiro de 2015 12:13, Flavio Henrique Araque Gurgel 
 fha...@gmail.com escreveu:

 Eu sei, eu sei... mas existem né? Nem tudo é perfeito AINDA.

 Comecei a escrever uma trilogia comparando o Oracle com o PostgreSQL e
 queria saber na opinião de vocês onde vocês acham que o Oracle leva
 vantagem sobre o PostgreSQL.

 Sem flames, por favor!!!


 Troll pode?
 Vantagem Oracle:
 Larry Ellison é bilionário.

 Desvantagem PostgreSQL:
 Tom Lane bebe cerveja na PgCon.

 Mas eu acho que o segundo se diverte mais :)
 ___
 pgbr-geral mailing list
 pgbr-geral@listas.postgresql.org.br
 https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral



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


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

[pgbr-geral] Problema de autenticação - postgres_fdw

[Fabiano Machado Dias]

Prezados,

Estou tendo um problema relativo a autenticação com usuários normais
usando o postgres_fdw, usei como exemplo o roteiro [1], porém só está
funcionando para super usuários, já revisei o pg_hba.conf e está tudo com
MD5, os usuários e senhas são válidos.

Procurei referencia sobre o assunto mas só encontrei algo relacionado do
dblink.

Segue meu passo a passo:

CREATE EXTENSION postgres_fdw;

CREATE SERVER testefdw FOREIGN DATA WRAPPER postgres_fdw OPTIONS (host
'ip_do_servidor', port '5432', dbname 'banco_teste');

CREATE USER MAPPING FOR postgres SERVER testefdw OPTIONS (user
'usuario_xyz',password 'xyz');

CREATE USER MAPPING FOR usuario_comum SERVER testefdw OPTIONS (user
'usuario_xyz',password 'xyz');

CREATE FOREIGN TABLE tabela_fdw (codigo varchar)  SERVER testefdw OPTIONS
(table_name 'tabela');

postgres: SELECT * FROM tabela_fdw; -- OK! (Select, insert, update, tudo
funcionando!)

SET SESSION AUTHORIZATION 'usuario_comum';

usuario_comum: SELECT * FROM tabela_fdw --
*ERROR:  password is required*
*DETALHE:  Non-superuser cannot connect if the server does not request a
password.*
*DICA:  Target server's authentication method must be changed.*

Link:
[1] -
http://michael.otacoo.com/postgresql-2/postgres-9-3-feature-highlight-postgres_fdw/

Alguém pode me dar uma luz?

Abraço,
Fabiano Machado Dias
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Problema de autenticação - postgres_fdw

[Fabiano Machado Dias]

Já ia esquecendo:
Postgresql 9.3.5
Debian 7 Stable


Em 11 de novembro de 2014 14:02, Fabiano Machado Dias 
fabi...@wolaksistemas.com.br escreveu:

 Prezados,

 Estou tendo um problema relativo a autenticação com usuários normais
 usando o postgres_fdw, usei como exemplo o roteiro [1], porém só está
 funcionando para super usuários, já revisei o pg_hba.conf e está tudo com
 MD5, os usuários e senhas são válidos.

 Procurei referencia sobre o assunto mas só encontrei algo relacionado do
 dblink.

 Segue meu passo a passo:

 CREATE EXTENSION postgres_fdw;

 CREATE SERVER testefdw FOREIGN DATA WRAPPER postgres_fdw OPTIONS (host
 'ip_do_servidor', port '5432', dbname 'banco_teste');

 CREATE USER MAPPING FOR postgres SERVER testefdw OPTIONS (user
 'usuario_xyz',password 'xyz');

 CREATE USER MAPPING FOR usuario_comum SERVER testefdw OPTIONS (user
 'usuario_xyz',password 'xyz');

 CREATE FOREIGN TABLE tabela_fdw (codigo varchar)  SERVER testefdw OPTIONS
 (table_name 'tabela');

 postgres: SELECT * FROM tabela_fdw; -- OK! (Select, insert, update, tudo
 funcionando!)

 SET SESSION AUTHORIZATION 'usuario_comum';

 usuario_comum: SELECT * FROM tabela_fdw --
 *ERROR:  password is required*
 *DETALHE:  Non-superuser cannot connect if the server does not request a
 password.*
 *DICA:  Target server's authentication method must be changed.*

 Link:
 [1] -
 http://michael.otacoo.com/postgresql-2/postgres-9-3-feature-highlight-postgres_fdw/

 Alguém pode me dar uma luz?

 Abraço,
 Fabiano Machado Dias

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

Re: [pgbr-geral] Problema de autenticação - postgres_fdw

[Fabiano Machado Dias]

Achei o problema!

Estava testando em outra instância no mesmo servidor e o pg_hba.conf dessa
instância de teste estava como TRUST, por isso que não funcionava! Erro
meu, estava olhando o arquivo da instância errada! O próprio hint do erro
me dizia o que era! rsrsrs

Abraço,
Fabiano Machado Dias

Em 11 de novembro de 2014 14:06, Fabiano Machado Dias 
fabi...@wolaksistemas.com.br escreveu:

 Já ia esquecendo:
 Postgresql 9.3.5
 Debian 7 Stable


 Em 11 de novembro de 2014 14:02, Fabiano Machado Dias 
 fabi...@wolaksistemas.com.br escreveu:

 Prezados,

 Estou tendo um problema relativo a autenticação com usuários normais
 usando o postgres_fdw, usei como exemplo o roteiro [1], porém só está
 funcionando para super usuários, já revisei o pg_hba.conf e está tudo com
 MD5, os usuários e senhas são válidos.

 Procurei referencia sobre o assunto mas só encontrei algo relacionado do
 dblink.

 Segue meu passo a passo:

 CREATE EXTENSION postgres_fdw;

 CREATE SERVER testefdw FOREIGN DATA WRAPPER postgres_fdw OPTIONS (host
 'ip_do_servidor', port '5432', dbname 'banco_teste');

 CREATE USER MAPPING FOR postgres SERVER testefdw OPTIONS (user
 'usuario_xyz',password 'xyz');

 CREATE USER MAPPING FOR usuario_comum SERVER testefdw OPTIONS (user
 'usuario_xyz',password 'xyz');

 CREATE FOREIGN TABLE tabela_fdw (codigo varchar)  SERVER testefdw OPTIONS
 (table_name 'tabela');

 postgres: SELECT * FROM tabela_fdw; -- OK! (Select, insert, update, tudo
 funcionando!)

 SET SESSION AUTHORIZATION 'usuario_comum';

 usuario_comum: SELECT * FROM tabela_fdw --
 *ERROR:  password is required*
 *DETALHE:  Non-superuser cannot connect if the server does not request a
 password.*
 *DICA:  Target server's authentication method must be changed.*

 Link:
 [1] -
 http://michael.otacoo.com/postgresql-2/postgres-9-3-feature-highlight-postgres_fdw/

 Alguém pode me dar uma luz?

 Abraço,
 Fabiano Machado Dias



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

Re: [pgbr-geral] PGDay Campinas - Quem vai?

[Fabiano Machado Dias]

E aí!

Também vou!

Abraço,
Fabiano Machado Dias

Em 9 de setembro de 2014 11:59, JotaComm jota.c...@gmail.com escreveu:

 Opa,

 Estarei por lá.

 Abraços

 Em 9 de setembro de 2014 10:34, Fabiano Abreu fabianoabreual...@gmail.com
  escreveu:

 Amanha participarei pela primeira vez do PGDay, pelo que promete, o
 evento será show, quem vai?

 Vamos marcar o almoço com a turma aqui da comunidade?

 ​Fabiano Abreu
 paposql.blogspot.com.br http://www.paposql.blogspot.com.br
 (65) 9939-5289​

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




 --
 JotaComm
 http://jotacomm.wordpress.com

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


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

Re: [pgbr-geral] Ferramenta para programação

[Fabiano Machado Dias]

Que Ferramenta/IDE/Editor usar para programar para postgre? Estou
 criando uma funções com o pgModeler, mas não estou muito satisfeito.
 Também me incomoda sair escrevendo várias funções sem uma validação de
 sintaxe e só perceber erros na hora de rodar o script.


Atualmente estou usando o SublimeText para Linux, pra Windows costumava
usar o Textpad, em ambos você pode adicionar um comando via shell que
executa o arquivo no banco e retorna os resultados no editor.

Segue um link explicando como fazer no Sublime.

http://www.youtube.com/watch?v=tPd4m3PLVqU

No meu caso nem precisei utilizar o parâmetro -o como está no vídeo, mesmo
rodando diretamente o retorno será exibido.

Em ambos os editores você pode adicionar highlight syntax.

Não é uma solução ideal, mas em minha opinião é melhor que o Query Tool do
pgadmin

Att,
Fabiano Machado Dias
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Formato de data

[Fabiano Machado Dias]

Boa noite pessoal.
Como sou iniciante no assunto estou com uma dúvida.
Ao criar um campo do tipo date ou timestamp o postgre guarda a data no 
formato YMD '2014-05-20' por padrão. Como posso alterar esse formato 
de data para o padrão brasileiro de forma que afete todos os campos de 
data que eu possa vir a criar?


E se é aconselhável realizar essa configuração?

Grato

Stanley Mendes
Estudando PostgreSQL
@StanleyMendesF




Referente ao armazenamento vide as respostas dos outros colegas, para 
apresentar a data em determinado formato você pode alterar um parâmetro 
de sessão:


set datestyle to sql, dmy;
select current_date;

Consulte: 
http://www.postgresql.org/docs/9.1/static/datatype-datetime.html#DATATYPE-DATETIME-OUTPUT-TABLE


Att,
Fabiano Machado Dias
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] FISL15

[Fabiano Machado Dias]

Não me inscrevi, mas vou passar por lá.

Att,
Fabiano


2014-04-23 13:46 GMT-03:00 Fabrízio de Royes Mello fabri...@timbira.com.br
:

 Pessoal,

 Alguém ai vai ao FISL15 [1] ?

 Att,

 [1] http://softwarelivre.org/fisl15

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

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

Re: [pgbr-geral] Melhor servidor para Banco de dados

[Fabiano Machado Dias]

Debian !


Em 23 de julho de 2013 11:26, Itamar Reis Peixoto
ita...@ispbrasil.com.brescreveu:

 2013/7/23 Carlos Antônio Pereira (VidaUTI) carlosanto...@utivida.com.br:
  Bom dia, senhores.
  Estou fazendo uns testes com um servidor de banco de dados
  utilizando PostgreSQL 9.2 com FreeBSD.
 
  Sempre utilizei o Fedora (atualmente a versão 19) em servidores
  aqui
  da empresa.
 
  Li alguns artigos que mencionam o FreeBSD com um algorítmo
  diferenciado para sistemas multiprocessados, que trazem uma
  performance de 35% a 45% acima de outros servidores e de até
  15% acima
  das distribuições Linux quando
  utilizado o PostgreSQL.
 
  Gostaria de saber a opinão de vocês a respeito e se há alguma
  distribuição Linux que seja mais indicada para Servidores
  de Banco de Dados PostgreSQL.
 
  Att Carlos


 o que tenho a dizer é que é o proprio Tom Lane quem compila os pacotes
 do postgresql para o fedora.



 

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

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

Re: [pgbr-geral] Tabela já nasceu lenta, pode?

[Fabiano Machado Dias]

Em 16-07-2013 09:03, Cicero Neto escreveu:
--corte--
Caso use a clausura WHERE pririze-a INVERTENTO a ordem dos campos 
EXE:- WHERE CAMPO4,3,2,1.

--corte--


Bom dia,

Você pode indicar alguma documentação onde informa isto?

Já li toda a documentação do PostgreSQL, principalmente a parte de 
otimização e reescrita de SQL e não lembro de algo informando que a 
ordem de campos no WHERE tem impacto no desempenho, inclusive já fiz 
testes e nunca observei alteração.


Como já faz um tempo que li gostaria de saber de onde você tirou esta 
informação, posso estar enganado, mas acredito que não exista nenhuma 
relação na ordem do WHERE em relação a desempenho na consulta.


Abraço,
Fabiano Machado Dias

 * Português - detectado
 * Inglês
 * Português

 * Inglês
 * Português

javascript:void(0);#
___
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 já nasceu lenta, pode?

[Fabiano Machado Dias]

Em 17-07-2013 12:57, Cicero Neto escreveu:

Isso nada tem a ver com postgres, mas sim com SQL, vide...

http://pt.wikipedia.org/wiki/SQL



Opa, li e não vi onde diz isso. Uma coisa é índice, outra é ordem dos 
campos do WHERE influenciar no desempenho. Se me enganei por favor 
compartilhe.


Abraço,
Fabiano Machado Dias
___
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 já nasceu lenta, pode?

[Fabiano Machado Dias]

Em 17-07-2013 15:09, Euler Taveira escreveu:

Se o outro banco de dados faz isso, ele está anos-luz atrás do Postgres
-- que já faz isso a bastante tempo. Porém, duvido que isso seja verdade
no banco de dados do Larry.


Opa, e aí Euler tudo blz? Fazia um tempão que só vinha acompanhado a 
lista, porém essa questão me deixou bem curioso.


Atualmente venho trabalhando bastante com Oracle, principalmente com 
PL/SQL e o comportamento é praticamente o mesmo do Postgres nessa 
questão, porém é muito difícil conseguir informações detalhadas sobre o 
funcionamento interno dele, apesar de existir muita documentação ela não 
tem a mesma profundidade que a do Postgres, pelo menos o que pesquisei 
até agora.


Gostei do debate porque estava preparando uma palestra para o PGBR deste 
ano justamente sobre alguns mitos sobre o PG e SQL em geral, mas 
infelizmente este ano não vou poder visitar nosso amigo Bueno. 
Compromissos profissionais e pessoais acontecerão no mesmo período.


Grande abraço e obrigado pela explanação.

Fabiano Machado Dias

 * Português - detectado
 * Inglês
 * Português

 * Inglês
 * Português

javascript:void(0);#
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Distribuição Linux Servidor

[Fabiano Machado Dias]

Em 28-09-2012 12:04, Luiz Rafael Culik escreveu:
 Ola

 Pessoalmente Mil vezes linha RH do que debian para servidor postgresql

 []s
 Luiz


Eu já tenho a opinião contrária, antes um Debian do que qualquer outra 
distro baseada em Red Hat, outra coisa, estou falando de Debian e não 
Ubuntu ou outra distro baseada nele!

Minha opinião:

Debian + XFS

ReiserFS era uma boa opção antigamente, mas o seu desenvolvimento está 
praticamente estagnado, XFS é confiável e tem um desempenho muito bom.

Além disso você pode personalizar algumas opções no File System que é 
bem fácil no Debian, coisa que as vezes só recompilando o Kernel em 
outras distros.

Me lembro de uma palestra que sempre quis ver e nunca tive a 
oportunidade que era Debian, o melhor SO para o melhor banco ou algo 
assim!

Não é Fike? rsrs

Abraço,
Fabiano Machado Dias
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

[pgbr-geral] PostgreSQL Magazine

[Fabiano Machado Dias]

Bom dia,

Não sei se já foi divulgado, saiu a edição da PostgreSQL Magazine

Segue os links:

Leitura Online:http://pgmag.org/01/read
Versão em PDF para download:http://pgmag.org/01/download

Abraço a todos,
Fabiano Machado Dias


  *
  * Inglês
  * Português

  * Inglês
  * Português

javascript:void(0);
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Postgres Embarcado Existe?

[Fabiano Machado Dias]

Em 11-11-2011 09:49, Alexsandro Haag escreveu:
 Gente, que é isso, não precisa arriscar os dados de ninguém.  Embutir o
 PostgreSQL é muito simples, mesmo em MS Windows, como eu já expliquei; e nem
 Firebird nem SQLite são minimamente seguros…
 Talvez uma chamada silenciosa do InnoSetup para o instalador do
 Postgres? Alguém já testou isso?

Marcelo,

Ainda não entendi porque você precisa embarcar o Postgres, você vai 
usar o aplicativo em terminais diferentes e ter bases descentralizadas? 
Só quer fazer um instalador silencioso? É um hardware diferente ou são 
terminais normais?

Se vai desenvolver em Delphi qual é a dificuldade de colocar em o 
Postgres em uma das máquinas e fazer o acesso pela rede?

Acho que você está vendo problemas demais em algo que é extremamente 
simples de resolver. Ou eu não entendi nada! :)


Abraço,
Fabiano Machado Dias


*
* Inglês
* Português

* Inglês
* Português

javascript:void(0);
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] pgadmin

[Fabiano Machado Dias]

Em 28-10-2011 12:53, Danilo Silva escreveu:
 Uso ubuntu-10.04 32 bits

Instale as dependências primeiro, depois compile, eu faço assim:

aptitude -t squeeze-backports build-dep pgadmin3

Claro, você precisa colocar os repositórios backports no seu 
sources.list e rodar um aptitude update

Como vc usa Ubuntu, pode usar o repositório do debian sem problema. Mas 
acho que o Ubuntu já tem a última versão do pgadmin3

Qualquer coisa confira com um aptitude show pgadmin3

Abraço,
Fabiano Machado Dias

* Galego - detectado
* Inglês
* Português

* Inglês
* Português

javascript:void(0);
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Curso de DBA... compensa?

[Fabiano Machado Dias]

Em 11-10-2011 17:41, David Augusto escreveu:
 Estou procurando por cursos de especialização do PostgreSQL e me 
 deparei com esse: 
 http://www.dextra.com.br/servicos/treinamento/pg/pgdba.htm , gostaria 
 de opiniões com relação se este curso parece compensar o investimento, 
 ou se devo procurar outro curso ou se alguém já fez...

 Obrigado


 ___
 pgbr-geral mailing list
 pgbr-geral@listas.postgresql.org.br
 https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Fiz o curso de tunning lá, gostei bastante, profissionais qualificados e 
o conteúdo bem objetivo.

Na minha opinião tanto a 4Linux quanto a Dextra são excelentes centros 
de treinamento, no entanto estude antes, leia bastante, não chegue  
cru no curso assim você poderá fazer melhor proveito do conteúdo.

Abraço,
Fabiano Machado Dias
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Curso de DBA... compensa?

[Fabiano Machado Dias]

Em 11-10-2011 17:41, David Augusto escreveu:
 Estou procurando por cursos de especialização do PostgreSQL e me 
 deparei com esse: 
 http://www.dextra.com.br/servicos/treinamento/pg/pgdba.htm , gostaria 
 de opiniões com relação se este curso parece compensar o investimento, 
 ou se devo procurar outro curso ou se alguém já fez...

 Obrigado


 ___
 pgbr-geral mailing list
 pgbr-geral@listas.postgresql.org.br
 https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Fiz o curso de tunning lá, gostei bastante, profissionais qualificados e 
o conteúdo bem objetivo.

Na minha opinião tanto a 4Linux quanto a Dextra são excelentes centros 
de treinamento, no entanto estude antes, leia bastante, não chegue  
cru no curso assim você poderá fazer melhor proveito do conteúdo.

Abraço,
Fabiano Machado Dias
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

[pgbr-geral] Erro cadastro de palestra / palestrante

[Fabiano Machado Dias]

E aí pessoal, sei que estou encima da hora, mas estou tentando me 
cadastrar no sistema para enviar uma palestrar e não está funcionando.

Diz que o Cadastro do Palestrante falhou

Alguém pode me dar uma luz?

Abraço,
Fabiano
___
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 cadastro de palestra / palestrante

[Fabiano Machado Dias]

Funcionou! Fiz outro cadastro e foi!
Abraço,
Fabiano

Em 8/9/2011 20:38, Fabiano Machado Dias escreveu:
 E aí pessoal, sei que estou encima da hora, mas estou tentando me
 cadastrar no sistema para enviar uma palestrar e não está funcionando.

 Diz que o Cadastro do Palestrante falhou

 Alguém pode me dar uma luz?

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


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

Re: [pgbr-geral] Function com retorno de query

[Fabiano Machado Dias]

Minha PL foi com quebra de linha errada no email anterior, segue 
bonitinha agora!


DROP TYPE IF EXISTS fnc.funcao2_retornotype_retorno CASCADE;
CREATE TYPE fnc.funcao2_retornotype_retorno AS (
 codigoVARCHAR,
 descricao VARCHAR);

CREATE OR REPLACE FUNCTION fnc.funcao2_retornotype(pTipo INTEGER)
RETURNS SETOF fnc.funcao2_retornotype_retorno AS
$$
DECLARE
 rRetorno fnc.funcao2_retornotype_retorno;
BEGIN
 IF pTipo = 1 THEN
 RETURN QUERY (SELECT codigo,descricao FROM situacaonfe ORDER BY 
codigo LIMIT 10);
 ELSIF pTipo = 2 THEN
 FOR rRetorno IN SELECT codigo,descricao FROM situacaonfe ORDER 
BY codigo LIMIT 10
 LOOP
 RETURN NEXT rRetorno;
 END LOOP;
 ELSE
 RAISE EXCEPTION 'Escolha um tipo(1 ou 2)!';
 END IF;
 RETURN;
END;
$$
LANGUAGE plpgsql;


Chamada:

SELECT * FROM fnc.funcao2_retornotype(2);
--SELECT fnc.funcao2_retornotype(2);
--SELECT (fnc.funcao2_retornotype(2)).*;
--SELECT (fnc.funcao2_retornotype(2)).descricao;
___
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.0.4 + Sistema de arquivo

[Fabiano Machado Dias]

 A afirmação do Euler me fez lembrar de um recente episódio meu em um
 cliente com subscrição da Redhat.
 Ele pagou pelo suporte adicional ao XFS pra obter milissegundos de
 tempo de resposta em algumas consultas e, naquele caso, valeu a pena.
 Mas eram milhões de transações/dia, aí valeu a pena.
 Pra comprovar tudo foram necessários testes exaustivos, era um
 ambiente grande e a grana envolvida permitia e até exigia tudo isso.

 Eu já usei ext2 em Redhat (Fabio Telles vai atirar em mim) num
 ambiente rápidíssimo e não queriam pagar pelo XFS.
 Foram necessários cuidados especiais com o backup, nobreak e uso de
 RAID 10, o que mesmo assim não garante a perda de algumas transações
 em caso de falha do servidor. O cliente estava ciente do risco e
 assumiu.

 []s
 Flavio Gurgel
 ___
 pgbr-geral mailing list
 pgbr-geral@listas.postgresql.org.br
 https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Pior que o EXT2 é muito rápido, será que um dia teremos um sistema de 
arquivos com a velocidade do EXT2 e com a segurança do XFS?

Se a performance é um item crítico vale a pena fazer uma partição com 
EXT2 para os índices? Ainda não precisei fazer isso em nenhum cliente, 
mas acho uma alternativa.

Lembro que eu tinha um script pronto para rodar o fsck quando o modo 
automático não dava conta!

Época do Red Hat, Mandrake, Conectiva! Bah, to ficando velho.

Abraço,
Fabiano Machado Dias

Abraço,
Fabiano Machado Dias
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Alter table add column

[Fabiano Machado Dias]

Em 30/8/2011 08:52, Thiago Godoi escreveu:

Leandro,

A chave natural é do tipo texto, por isso estou criando uma chave 
artificial. Comparar números é mais barato do que texto? Foi por isso 
que criei-a.


Fabiano,

Obrigado pelas respostas, eu deixei para criar os índices depois 
mesmo, e o autovacuum está ativado. Já acabou de rodar a alteração e o 
espaço utilizado na partição voltou ao normal.


Abraços


Essa questão do tipo inteiro, bigint vs char, varchar, text é bem complexa.

Você encontra no histórico da lista diversas opiniões, muitas delas 
dizendo que não há diferença de desempenho outra dizendo que tem, então 
a melhor maneira é testar.


Antes de tudo leia, depois teste!

Falando de performance mesmo:
http://archives.postgresql.org/pgsql-performance/2004-11/msg00336.php 
(Bem antigo, mas ainda válido)
http://archives.postgresql.org/pgsql-sql/2008-09/msg00098.php (Leia a 
trilha inteira)

http://it.toolbox.com/blogs/database-soup/primary-keyvil-part-i-7327
http://it.toolbox.com/blogs/database-soup/primary-keyvil-part-ii-7345
http://it.toolbox.com/blogs/database-soup/primary-keyvil-part-iii-7365

Aqui mais sobre armazenamento e troca de estrutura:
http://www.postgresonline.com/journal/archives/154-In-Defense-of-varcharx.html
http://www.depesz.com/index.php/2010/03/02/charx-vs-varcharx-vs-varchar-vs-text/

Abraço,
Fabiano Machado Dias

 * Inglês - detectado
 * Inglês
 * Português

 * Inglês
 * Português

javascript:void(0);
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Alter table add column

[Fabiano Machado Dias]

Em 30/8/2011 13:48, Leandro Guimarães Faria Corcete DUTRA escreveu:

Le 2011.A.29 23h24, Fabiano Machado Dias a écrit :

Em 29/8/2011 23:01, Leandro Guimarães Faria Corce DUTRA escreveu:

Le 2011-A-29  22h33, Thiago Godoi a écrit :

Após essa carga… adicionei um campo… bigserial, com o comando:

Aí vem a velha pergunta… para quê?  Geralmente, uma adição dessas é
porque não se percebeu ou declarou uma chave natural.

Mas não respondeu a pergunta dele! Aliás, como sempre né Leando?!

De propósito.  Vide que minha pergunta foi muito mais útil e essencial
que tua resposta.


O problema é esse, nunca responde nada objetivamente! A pessoa está lá 
com um problema, posta uma dúvida esperando uma solução ou uma luz e 
recebe uma resposta do tipo:


Reveja o seu modelo

Bah isso é de uma ajuda imensa!!! Podia responder a dúvida e depois 
complementar!


Abraço,
Fabiano Machado Dias


 * Inglês - detectado
 * Inglês
 * Português

 * Inglês
 * Português

javascript:void(0);
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Alter table add column

[Fabiano Machado Dias]

Em 30/8/2011 13:48, Leandro Guimarães Faria Corcete DUTRA escreveu:

Le 2011.A.30 10h42, Fabiano Machado Dias a écrit :

Essa questão do tipo inteiro, bigint vs char, varchar, text é bem complexa.

Não é.


Putz, esses dias atrás lendo o Blog do Bruce lá estava essa discussão e 
a opinião dele falando que a discussão é válida e provavelmente será uma 
eterna flame war






Você encontra no histórico da lista diversas opiniões, muitas delas
dizendo que não há diferença de desempenho outra dizendo que tem

Não encontra.  Se encontrar, verá que quem diz ter não fundamentou, ou
confundiu com outras questões (como chaves simples ou compostas,
naturais ou artificiais).



a melhor maneira é testar.

Nah, a melhor maneira é ignorar a menos que se tenha um indício forte de
que o índice associado à chave natural em questão é um gargalo.  Testar
a troco de nada é otimização precoce, desperdiçando tempo que poderia
ser melhor empregado buscando otimizações reais, melhorias de
funcionalidade ou simples qualidade de vida.



Cruzes! Teste não serve pra nada então! rsrsrs

Se deu o trabalho de ter os links que enviei?

Será que todo mundo tá errado e só o você certo? Acho até engraçado que 
você trata isso como uma regra. Sendo que bases de dados são tão 
diferentes de uma para outra e nunca existe uma fórmula mágica e que se 
deva seguir a risca!


Prefiro ficar com as diversas opiniões de quem tem bases reais para 
cuidar no dia a dia e não apenas na teoria!


Abraço,
Fabiano Machado Dias

http://archives.postgresql.org/pgsql-performance/2004-11/msg00336.php 
(Bem antigo, mas ainda válido)
http://archives.postgresql.org/pgsql-sql/2008-09/msg00098.php (Leia a 
trilha inteira)

http://it.toolbox.com/blogs/database-soup/primary-keyvil-part-i-7327
http://it.toolbox.com/blogs/database-soup/primary-keyvil-part-ii-7345
http://it.toolbox.com/blogs/database-soup/primary-keyvil-part-iii-7365
http://www.postgresonline.com/journal/archives/154-In-Defense-of-varcharx.html
http://www.depesz.com/index.php/2010/03/02/charx-vs-varcharx-vs-varchar-vs-text/

 * Inglês - detectado
 * Inglês
 * Português

 * Inglês
 * Português

javascript:void(0);
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Alter table add column

[Fabiano Machado Dias]

Em 30/8/2011 14:39, Leandro Guimarães Faria Corcete DUTRA escreveu:

Le 2011.A.30 14h10, Fabiano Machado Dias a écrit :

Em 30/8/2011 13:48, Leandro Guimarães Faria Corcete DUTRA escreveu:

Le 2011.A.30 10h42, Fabiano Machado Dias aécrit :

Essa questão do tipo inteiro, bigint vs char, varchar, texté  bem complexa.

Nãoé.

Putz, esses dias atrás lendo o Blog do Bruce lá estava essa discussão e
a opinião dele falando que a discussão é válida e provavelmente será uma
eterna flame war

Referências?  Aposto que incorreste nalguma das confusões que mencionei.


Estava no blog dele, nos trechos de emails que ele retira da lista 
performance!


Hoje o blog tá off, senão mandava o link!

http://momjian.us/main/blogs/pgblog.html





Cruzes! Teste não serve pra nada então! rsrsrs

Serve.  Quando se tem algo a testar que não uma mera conjectura de
otimização precoce.


O cara tem uma base já de um tamanho considerável, estava mudando as 
colunas justamente para testar! Otimização precoce em base de produção







Se deu o trabalho de ter os links que enviei?

Queres saber há quantos anos?  Ou queres uma explicação de cada um para
mostrar que não são bem isso que entendestes?


Quero!







Será que todo mundo tá errado e só o você certo?

Já virou ad hominem e non sequitur, e ainda colocando palavras na minha
boca.



Putz, já vi que não leu mesmo os links, pelo menos os da lista de 
discussão! Deixa pra lá!



Acho até engraçado que
você trata isso como uma regra. Sendo que bases de dados são tão
diferentes de uma para outra e nunca existe uma fórmula mágica e que se
deva seguir a risca!

Pelo jeito, faltou entenderes o que são regras.


rsrsrs, tá bom!





Prefiro ficar com as diversas opiniões de quem tem bases reais para
cuidar no dia a dia e não apenas na teoria!

Hm, é para comparar experiência?


Capaz, ninguém nunca ganharia de você! rsrs,

Brincadeiras a parte, vc mesmo diz que faz um bom tempo que não lida com 
base de dados e programação! Talvez tenha se esquecido dos pepinos do 
dia a dia e ficado com a teoria em mente, que é ótima, mas as vezes não 
resolve!







Abraço,
Fabiano Machado Dias

 * Inglês - detectado
 * Inglês
 * Português

 * Inglês
 * Português

javascript:void(0);
Abraço,
Fabiano Machado Dias
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Alter table add column

[Fabiano Machado Dias]

Em 30/8/2011 14:42, Leandro Guimarães Faria Corcete DUTRA escreveu:
 Le 2011.A.30 14h9, Fabiano Machado Dias a écrit :
 O problema é esse, nunca responde nada objetivamente! A pessoa está lá
 com um problema, posta uma dúvida esperando uma solução ou uma luz e
 recebe uma resposta do tipo:

 Reveja o seu modelo
 Quando aplicável, isso é muito mais objetivo que responder uma dúvida
 diretamente e ajudar a pessoa a perder tempo num caminho errado.


Sim, mas você nunca responde! Esse é o problema, e pelo visto também não lê!

Vou repetir, já que você cortou:
Podia responder a dúvida e depois complementar!

Abraço,
Fabiano Machado Dias

___
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.0.4 + Sistema de arquivo

[Fabiano Machado Dias]

Minha aplicação é OLTP e costumo usar XFS, já usei EXT3 mas achei mais 
lento.

Já tem gente usando EXT4, dizem que é rápido e seguro, mas nunca 
coloquei em teste.

Vale a pena fazer uma comparativo entre XFS e EXT4

Abraço,
Fabiano Machado Dias





Em 30/8/2011 17:19, Diogo Borsoi escreveu:
 Pessoal,

 Qual sistema de arquivo mais indicado para um BD PG 9.0.4, com muita
 consulta e inserção de dados?


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


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

Re: [pgbr-geral] Alter table add column

[Fabiano Machado Dias]

Em 29/8/2011 23:01, Leandro Guimarães Faria Corce DUTRA escreveu:
 Le 2011-A-29  22h33, Thiago Godoi a écrit :
   Após essa carga… adicionei um campo… bigserial, com o comando:

 ALTER TABLE X ADD COLUMN Y BIGSERIAL;
 Aí vem a velha pergunta… para quê?  Geralmente, uma adição dessas é
 porque não se percebeu ou declarou uma chave natural.




Mas não respondeu a pergunta dele! Aliás, como sempre né Leando?!


Thiago,

Se você adicionou uma coluna com um valor default não nulo ou está 
mudando o tipo de uma coluna existente, a tabela será toda reescrita, 
inclusive os seus índices.

Você pode melhorar o tempo excluindo os índices da tabela e depois 
recriando de novo e desabilitando o fsync (se for possível)!

http://www.postgresql.org/docs/9.0/interactive/sql-altertable.html

Depois que o o processo terminar rode um vacuum na tabela, provavelmente 
o espaço irá diminuir.

Abraço,
Fabiano Machado Dias

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

[pgbr-geral] OFF TOPIC - PostgreSQL: The most powerful software you can't pronounce

[Fabiano Machado Dias]

Muito legal, novas propostas de slogan e brincadeiras com o nome do banco!

http://momjian.us/main/blogs/pgblog/2010.html#January_29_2010

Já escutei coisas do tipo Post, Postgre, Postgree, Postgru e 
outras bizarrices, sem contar aqueles que confundem Progress com Postgres.

Eita nomezinho que gera discussão!

Abraço a todos,

Fabiano Machado Dias
___
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 em Thread

[Fabiano Machado Dias]

  
  
Bruno, sua dvida foi respondida pelo Shander, se voc quer que as
funes ocorram em processos paralelos voc precisa iniciar cada uma
com uma conexo diferente. 

Agora no sei se isso vai te trazer performance, talvez executando
cada funo em uma chamada diferente dentro da mesma conexo seja
melhor do que abrir novas conexes com o banco, como no conheo sua
aplicao e nem sua base s testando.

Abrao,
Fabiano Machado Dias



Em 11/8/2011 13:55, Bruno Silva escreveu:

  Quando resolver eu posto. Obrigado!
  
  
  
  ___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral




-- 
  
  
  
  Atenciosamente, 

Fabiano Machado Dias
Analista de Sistemas e Negcios
Administrador de Sistemas Linux
DBA PostgreSQL
Wolak Tecnologia em Informtica e Gesto Ltda.
51 9826-8912
fabi...@wolaksistemas.com.br
fabi...@erpws.com.br
 mdfabiano  
 fabiano...@hotmail.com




  

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

Re: [pgbr-geral] Base antiga

[Fabiano Machado Dias]

Então o seu problema é com o aplicativo e não com o banco de dados. Você 
configurou os acessos ao banco? Liberou as conexões? Tem alguma mensagem 
no log?


Att,
Fabiano Machado Dias

Em 11/8/2011 13:53, Cristiano Alves escreveu:
Eu fiz o dump de um base que estava numa versão do banco 8.2.11 e 
restaurei a base em outro computador com a versão do postgresql 
9.0.4.1, a base foi restaurada consigo fazer selects no banco e tudo, 
mas quando vou entrar no sistema fica dando mensagem de erro , dizendo 
que foi identificado problemas com a conexão com o banco de dados.



Att,
Cristiano Paiva Alves
TI- Tecnologia da Informação
Irmandade da Santa Casa de Caridade de Alegrete
Fone: (55) 3422 2888
Ramal: 274/302

Em 11/08/2011 às 13:35 horas, pgbr-geral@listas.postgresql.org.br 
escreveu:


2011/8/11 Cristiano Alvescristi...@santacasaalegrete.org.br  
mailto:cristi...@santacasaalegrete.org.br:
  Quais detalhes faltam?

Primeiro, seguir a netiqueta (RFC 1855), respondendo após a mensagem e
cortando o que não for relevante à resposta.

Segundo, o que exatamente deu errado: versão de base e utilitário de
origem, de destino, e mensagem(ns) de erro.


-- 
Skype:leandro.gfc.dutra?chat   Yahoo!: ymsgr:sendIM?lgcdutra

+55 (61) 3546 7191 Google Talk: xmpp:leand...@jabber.org
+55 (11) 9406 7191  MSNIM:chat?contact=lean...@dutra.fastmail.fm
sip:leand...@iptel.org ICQ: AIM:GoIM?screenname=61287803
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral  
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral



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

Re: [pgbr-geral] Função em Thread

[Fabiano Machado Dias]

Em 11/08/2011 15:11, Bruno Silva escreveu:
 Seguinte tenho cerca de 50 funções que podem ser chamadas de modo
 independente. Tipo se o usuário precisar da estatística A , ele chama a
 função estA(date, date).
 Para geração de um determinado relatório que é composto por essas 50
 funções, criei uma façade que chama uma por uma inserindo o resultado em
 uma tabela temporária. E ao término ela imprime o conteúdo dessa tabela
 temporária.
 Seguindo No estilo:  select * from
 facade_relatorio('2011-01-01','2011-07-01');

Porque você não cria uma tabela real no sistema para esse relatório e 
manda gravar os dados diretamente nela, aí sim você poderia disparar 
cada função separadamente usando conexões diferentes ou até a mesma 
conexão mas com chamadas distintas.

Para resolver o problema de vários usuários emitirem o mesmo relatório e 
listar informações trocadas uns dos outros, você poderia criar algum 
tipo de identificador de sessão, por usuário, login, data etc...

Da maneira que está realmente não há como fazer esse processo de forma 
paralela.

Sei lá, só uma idéia, como sempre teria que testar pra ver se funciona.

Abraço,
Fabiano Machado Dias
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Retornar id inserido

[Fabiano Machado Dias]

Em 22/7/2011 00:29, Leandro DUTRA escreveu:
 2011/7/22 Vinicius Santosvinicius.santos.li...@gmail.com:
 Ao inserir um novo registro na tabela camisas o Postgres precisa fazer
 a verificação de chave estrangeira, na tabela cores.  Por ser uma
 chave estrangeira VACHAR(30) ou CHAR(30), por exemplo, é mais caro, para
 o Postgres que se fossê uma chave do tipo inteira?
 Não.  Talvez em casos muito, mas muito extremos mesmo, mas que eu
 saiba isso nunca foi demonstrado.

 Isso dito, tem um artigo interessante do David Fetter nalgum lugar
 recomendando evitar VARCHAR.  O CHAR funciona muito bem.


 Será que a performance cairia, pelo fato de o tipo não ser INT ?
 Não.


 Uma junção entre chaves simples é muito mais rápido que uma entre chave
 composta ?
 Não.


 Ou nestes casos o que manda mesmo é sempre o bom-senso? Vou utilizar
 uma chave artificial pois o tipo INT é mais rápido neste caso
 Não é bom senso, é ato reflexo.


Você tem algum material, livro, documentação oficial onde isso seja 
documentado com mais detalhes? No caso estou me referindo as 3 repostas, 
lembro de já ter procurado na documentação e não ter encontrado.

Não estou duvidando, apenas gostaria de ver algum artigo ou explicação 
mais consistente, já vi outras opiniões parecidas aqui na lista, mas 
nunca ninguém citou um material onde isso estivesse documentado.



 A vantagem de não fazer junções desnecessárias, e manter a modelagem
 limpa, é tentadora.
 E conceitualmente correta.


 Caso estas questões de tipo sejam apenas lendas urbanas não vejo
 motivo algum para chaves artificiais. Estou errado ?
 Há muitas ferramentas que forçam o programador a escrever cada parte
 de uma chave composta, por não terem operadores sobre um conjunto de
 variáveis.  Não tem nada a ver com modernidade, o Cobol já fazia isso
 direito há quarenta anos, pelo menos.  Isso leva os programadores a
 procurarem criar uma chave simples.  O problema é se criam chave
 artificial mesmo quando as naturais serviriam perfeitamente, e pior
 ainda quando esquecem de declarar as chaves naturais ao lado da
 artificial.

 Outra situação que pode exigir uma chave artificial é quando (1) as
 chaves naturais de uma relação (tabela) são todas compostas de muitos
 atributos, e (2) exportadas para várias relações filhas maiores que a
 pai, e (3) isso num volume muito, muito alto.  Aí poderia,
 eventualmente, acontecer da diferença de volume de dados armazenado e
 em memória ser significativa.

 Deve haver alguma outra exceção à regra de evitar chaves artificiais
 que não me lembro.  O que não há é exceção à regra de sempre declarar
 pelo menos uma chave natural, mesmo que se tenha sido obrigado a criar
 uma artificial.




Abraço,
Fabiano Machado Dias
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Versões do PostgreSQL

[Fabiano Machado Dias]

Nos poucos servidores Windows que tenho, o problema mais comum é quando 
ocorre um desligamento ou reinicialização incorreta e o postmaster.pid 
fica trancado.

Isso até já foi discutido aqui na lista. Basta mover o arquivo e iniciar 
novamente o serviço, mas é um problema digamos assim comum que ocorre 
no Windows, pode ser até que aconteça também no Linux, mas nunca ocorreu 
comigo.

No mais sempre prefira Linux, mas se tiver mesmo que ser no Windows 
fique atento! Muitas vezes o problema não é com o PostgreSQL e sim com o 
nosso amigo da MS!

Abraço,
Fabiano Machado Dias



Em 5/7/2011 13:33, George Rodrigues da Cunha Silva escreveu:
 On terça-feira, 5 de julho de 2011 13:23:15, Leandro DUTRA wrote:
 2011/7/5 Evandro Andersenevandro.ander...@gmail.com:
 Ambos
 Então, seriam ‘eles’.  E aí repito o que já disse quando morei em
 Londrina, dez anos atrás: o MS Windows é estável para quem nunca
 experimentou nada melhor.
 Pela minha experiência (versões  8.2) o PostgreSQL sempre foi estável
 em Windows.

 Não podemos esquecer, que existem clientes que já possuem um
 determinado setup, impossibilitando o uso de servers em outros SOs.
 Neste caso, não há muito o que fazer.


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

Re: [pgbr-geral] Mostrar a consulta recente da transação em aberto

[Fabiano Machado Dias]

Em 5/7/2011 14:36, Dickson S. Guedes escreveu:
 Em 5 de julho de 2011 14:33, Fabiano Machado Dias
 fabi...@wolaksistemas.com.br  escreveu:
 Já tentou o pgFouine?

 http://pgfouine.projects.postgresql.org/
 O problema está antes do pgFouine, Fabiano. O Sebastian quer
 identificar potenciais problemas na aplicação com transações que ficam
 abertas e não são comitadas, no entanto ele não tem as consultas
 geradas dentro dessas transações,


Mas será que habilitando o log_min_duration_statement ele não teria pelo 
menos o comando que iniciou a transação, daí com o pgfouine seria mais 
fácil de analizar o log e identificar pelo tempo da query. Pelo menos 
teria um ponto de partida para começar a trabalhar.

Sei lá, só uma idéia, teria que testar na prática pra ver se funfa!

Abraço,
Fabiano Machado Dias
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Sugestão de uso

[Fabiano Machado Dias]

Em 29/6/2011 11:56, Shander Lyrio escreveu:
 Em 29/06/2011 00:30, Fabiano Machado Dias escreveu:
 Fizemos uso de PL/pgSQL direto, e hoje após quase 5 anos do cliente
 piloto posso te dizer ficou acima do esperado.
   Da mesma forma que o colega que postou a pergunta sugeriu? Tudo via
 plpgsql?? Até mesmo as funções de insert, delete e update?? Eu também
 faço uso de plpgsql direto, mas não tudo!

   O que você esperava com isto e oque ficou melhor?

 --

Sim, temos uma PL que controla os comandos DML, ou seja, a interface 
passa os campos e ela se encarrega do resto.

Nós tínhamos um projeto audacioso pela frente, construir um software de 
gestão em menos de 2 anos, a contabilidade seria online (não existe 
exportação e geração, faz na hora!)  e já atendendo as obrigatoriedades 
do governo. (NFE, SPED, e-Lalur, Ato Cotepe etc), fora os módulos 
principais do sistema.

Queríamos automatizar as tarefas rotineiras do desenvolvimento mas sem 
perder a performance que tínhamos em outra linguagem, performance de 
telas, acesso rápido via cursores etc.

Tudo deveria ter controle relacional, colocamos todas as restrições no 
banco e começamos a desenvolver as PLs básicas.

Nós estávamos saindo de um projeto que usava PostgreSQL mas a camada de 
dados não era no banco, vi vários problemas de transação ocorrendo, sem 
contar os problemas com gatilhos e a lentidão, então resolvemos que os 
processos seriam implementados totalmente dentro das PLs.

O que queríamos era:

1 - Segurança nas transações,
2 - Centralizar o desenvolvimento
3 - Velocidade de desenvolvimento
4 - Acesso rápido aos dados pelo cliente

Conseguimos isso e muito mais, a modelagem mudou radicalmente, usamos a 
tão falada chave artificial para as PKs e fizemos as restrições devidas 
nas chaves naturais (UKs), assim conseguimos resolver os problemas do 
modelo físico e do lógico, claro que eles se misturam (não chegam ao 
usuário mas ao programador sim), mas pra nós não é problema, aliás nunca 
foi. (Por favor, não quero criar polêmica de novo rsrsrs, é só a minha 
resposta a pergunta do colega!)

Depois de trabalhar com tabelas em que a PK era composta por 16 campos e 
tinha que juntar mais mais outras 20 tabelas, abolimos as PKs  
compostas, isso me deu um ganho de performance bom e uma escrita rápida 
também, a criação de índices também ficou fácil.

Também criamos uma estrutura de controle para separar as Filiais e 
usamos bastante array em conjunto a interface.

Hoje tenho PLs que se modificam conforme a parametrização do sistema e 
que interagem com PLs que podem ser customizadas para atender uma 
determinada situação.

PLs que controlam a auditoria de outras PLs etc.

Fizemos um uso muito restrito de gatilhos, dá pra contar nos dedos 
quantos tem no sistema, afinal tenho o controle do que acontece nas PLs!

Bom, poderia te dar vários exemplos, dá uma olhada na palestra do pgcon 
de 2009, lá tem casos mais específicos do que fizemos.

Posso te dizer que hoje coloco a cabeça no travesseiro e durmo 
tranqüilo! rsrsrs

Nunca mais me preocupei com corrupções, dados inconsistentes, banco 
travando etc!!!

Estarei no PGBR esse ano, se alguém quiser ver isso funcionando de perto 
posso mostrar sem problemas.

Um grande abraço!

Fabiano Machado Dias


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


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

Re: [pgbr-geral] Sugestão de uso

[Fabiano Machado Dias]

Em 29/6/2011 14:06, Shander Lyrio escreveu:
 Em 29/06/2011 12:54, Fabiano Machado Dias escreveu:
 Sim, temos uma PL que controla os comandos DML, ou seja, a interface
 passa os campos e ela se encarrega do resto.
   Sério?

Sim, desenvolvemos o nosso próprio framework rsrs! Ela não faz só isso, 
além de escrever e controlar os comandos tem mais coisas que são 
controladas pela PL manutenção!

 Queríamos automatizar as tarefas rotineiras do desenvolvimento mas sem
 perder a performance que tínhamos em outra linguagem, performance de
 telas, acesso rápido via cursores etc.
   Você está dizendo que colocar tudo no PostGreSql tornou suas telas mais
 rápidas?? O que uma coisa tem haver com a outra?

Não o fato de colocar tudo no PostgreSQL e sim o fato de usar 
cursores, offset, sequencias temporárias etc... Desculpe se não fui claro!

 Tudo deveria ter controle relacional, colocamos todas as restrições no
 banco e começamos a desenvolver as PLs básicas.
   O que tem haver controle relacional com lógica de negócio em
 procedures para tudo dentro do banco de dados?

Conheço vários ERPs onde as restrições ficam na interface! Já vi bancos 
onde não existia uma constraint sequer, outros que só tinham 2 tipos de 
dados!!!

O fato de você organizar as transações dentro de uma PLs é o mesmo 
exemplo já citado. Ao invés de eu ter um código de baixa de estoque em 
alguma tela, ou procedure em alguma camada intermediária eu tenho uma PL 
que faz isso! É um conjunto de soluções e não apenas o uso de PLs, 
tentei passar uma idéia geral de como fizemos o desenvolvimento.

 Nós estávamos saindo de um projeto que usava PostgreSQL mas a camada de
 dados não era no banco, vi vários problemas de transação ocorrendo, sem
   Como assim a camada de dados não era o banco? Usava o PostGreSql para
 que então?

Era um sistema em 3 camadas, me referi mal, quis dizer que a camada de 
negócio não era no banco, existiam PLs que faziam alguns processos, mas 
a grande maioria era resolvida na camada intermediária e só gravava no 
banco.

 contar os problemas com gatilhos e a lentidão, então resolvemos que os
 processos seriam implementados totalmente dentro das PLs.
   Resolveram assim do nada, sem tentar descobrir o real problema?

Sim, descobrimos o problema, mas o sistema não era nosso e quando vimos 
o que o uso de gatilhos poderia causar tomamos a decisão e fazer 
diferente no nosso sistema.

O problema é quando um gatilho, dispara um gatilho que dispara outro 
E as vezes lá no quinto nível aquele quinto gatilho dispara o 
primeiro!!! Daí você tem além um baita problema uma produção parada!

 O que queríamos era:

 1 - Segurança nas transações,
   Isso não tem nada haver com tudo feito por PL's dentro do banco de
 dados. O Postgresql te garante isto de forma totalmente independente de
 pl's;

Sim, mas definimos que seria regra.

 2 - Centralizar o desenvolvimento
   Onde? no PostgreSql?

Sim, nas PLs.

 3 - Velocidade de desenvolvimento
   Escrever PL's é mais rápido que escrever código em qualquer outra
 linguagem?? Como fica o versionamento disso? Como são feitos testes
 unitários?

Existe diferença? PL/pgSql não é uma linguagem? Talvez você sinta falta 
de uma IDE, é isso? Temos uma IDE pra interface, Windev conhece? No mais 
uso o bom e velho pgadmin!

As versões são controladas por um software que nós mesmos desenvolvemos, 
eu sou um dos responsáveis pelos testes de versão.

 4 - Acesso rápido aos dados pelo cliente
   Onde PL's ajudam nisto a não ser em casos muito especiais já citados
 nesta thread diversas vezes?

Já citei um exemplo acima, sem contar a facilidade de poder alterar o 
comportamento do sistema sem ter que interferir no desenvolvimento com 
as PLs customizadas que a PL manutenção procura! Vide palestra.

 Conseguimos isso e muito mais, a modelagem mudou radicalmente, usamos a
 tão falada chave artificial para as PKs e fizemos as restrições devidas
 nas chaves naturais (UKs), assim conseguimos resolver os problemas do
 modelo físico e do lógico, claro que eles se misturam (não chegam ao
 usuário mas ao programador sim), mas pra nós não é problema, aliás nunca
 foi. (Por favor, não quero criar polêmica de novo rsrsrs, é só a minha
 resposta a pergunta do colega!)
   Mas não respondeu, aliás, estou muito mais confuso agora. O que tem
 haver a modelagem com o uso extensivo de PL's? Será que o problema
 inicial já não era a modelagem e você está achando que seus ganhos foram
 com o excesso de PL's mas na verdade foi com a mudança radical da modelagem?
Não, foi um conjunto de fatores, não existe mágica né! A modelagem 
ajudou a simplificar o desenvolvimento das PLs, as duas coisas andam 
juntas. De nada me adianta ter uma modelagem boa e um framework lento e 
cheio de bugs!

 Depois de trabalhar com tabelas em que a PK era composta por 16 campos e
   Acredito firmemente que você está confundindo uma restrição unique com
 PK. Acho que é limitação do meu cérebro mas não

Re: [pgbr-geral] Sugestão de uso

[Fabiano Machado Dias]

Em 29/6/2011 21:40, Shander Lyrio escreveu:
 Em 29/06/2011 20:07, Fabiano Machado Dias escreveu:
 O fato de você organizar as transações dentro de uma PLs é o mesmo
 exemplo já citado. Ao invés de eu ter um código de baixa de estoque em
 Inicia o bloco da transação antes da chamada da PL, chama a PL e encerra
 a transação. Se você usa PL achei que fazia isso.
   Eu uso, mas para mim está muito claro que você disse organizar
 transações dentro de uma PL. Dentro para mim ainda é diferente de
 fora como você citou agora. Leia por favor seus dois parágrafos acima,
 achei que você tivesse lido.

Toda a PL e os blocos de uma PL rodam numa transação, o que você não 
pode é alterar a transação dentro da PL, te dei um exemplo de como 
chamar várias PLs dentro de uma transação externa.

Organizar transações dentro de uma PL, ou seja, o que eu preciso que 
faça tudo ou não, ou baixa estoque ou não, ou quita uma duplicata ou 
não, ou grava ou não grava, ou dá ou desce!!! rsrsrsrs

Não vejo o que você fala como dentro ou fora, como já disse você se tem 
os seus procedimentos em PL nada de impede de um chamar o outro. E tb 
não vi que tipo de coisa você estava esperando, se conhece o 
funcionamento de transações e do banco não pensei que teria que te 
explicar isso.

Algumas referências:

http://pgdocptbr.sourceforge.net/pg80/plpgsql-structure.html (Em português)
http://www.postgresql.org/docs/9.0/static/plpgsql-structure.html (Mais 
atual, em inglês)
http://pgbr.postgresql.org.br/2009/palestras/aud1/plpgsql-roberto-mello.pdf



 A diferença é que você tem o controle, quantas vezes vi gente quebrando
 a cabeça porque só queria alterar um valor numa coluna e o banco travou!
 Travou pq esqueceu ou nem sabia que tinha um gatilho lá fazendo um monte
 de coisa!
   Não tem diferença de um gatilho chamando um outro e fazendo um monte de
 coisa de uma procedure chamando outras e fazendo um monte de coisa.
 Gatilhos nada mais são que chamadas para procedures.

Sim, tecnicamente sim, a diferença é que uma PL você que chama e não é 
disparada quando troca o telefone de um cadastro de cliente por exemplo!

 Você escrever todo um sistema, um framework, as tuas regras de negócio
 em uma ferramenta e ver ele simplesmente morrer é um trauma pra qualquer
 desenvolvedor.
   O SGDB também pode morrer. Uma linguagem inteira ou um SGDB inteiro é
 menos propenso a morrer do que uma mera ferramenta como o Clarion.
 Apostar todas as suas fichas em uma só tecnologia sempre será um risco,
 quem faz isto em uma ferramenta somente assume um risco muito maior como
 foi seu caso.

   Sinto muito pelo seu trauma, o que está fazendo hoje não resolve o
 problema da melhor forma, apenas resolve. Tudo poderia ser mais simples,
 mais testável e mais garantido que o que você tem hoje, se ser simples e
 testável não tem tanto valor assim para você, então está valendo.

Você conhece Clarion? Era uma linguagem inteira, na verdade vi o 
conceito de ferramenta RAD já incorporado no Clarion ainda em DOS. Era 
um espetáculo pra época, uma velocidade de desenvolvimento que nenhuma 
outra ferramenta tinha, pelo menos não as que conheci, e olha que já vi 
muita coisa.

Nas versões Windows continuou até a 7 e morreu. A partir daí usei de 
tudo, fiz cursos disso e daquilo, trabalhei em outros projetos, olhei 
ferramentas livres, pagas, etc...

Sabia que iria construir um novo software, para um outro ramo e em outra 
tecnologia e desta vez queria ficar o mais independente possível. (Ok, 
fiquei preso ao PG, mas isso eu já falei né)

Quanto a você achar que tudo poderia ser mais simples e testável e 
garantido, bom te garanto que já tenho isso atualmente, apesar de você 
discordar, é sua opinião e respeito.

 Vou te dar só um exemplo. Você precisa alterar a forma do cálculo do
 custo de todos os insumos de uma ficha técnica. Se a tua regra é na
 aplicação, vai ter que recompilar, gerar uma nova versão, substituir teu
 executável ou coisa similar. Faço isso hoje, mantenho a versão original,
 modifico, atualizo, rodo e não envolvo nenhuma outra parte a aplicação.
   Uma pequeno script em uma linguagem tipo o Python não era melhor? Não
 envolveria nem a aplicação, nem alteração no banco de dados. Digo isto
 porque uso algo deste tipo e uma aplicação minha. O script fica guardado
 no banco de dados e pode ser alterado em uma tela do sistema.

   Vamos supor que você fez uma alteração na sua procedure de calculo de
 custo na empresa A. Ok, um dia você percebe que tem um bug na procedure
 de cálculo de custos geral, cria um script para corrigir ela em todos os
 seus clientes e bam. Perdeu-se a alteração específica que está naquele
 cliente. Ok ok, você pode argumentar que faz isto cliente por cliente
 para ser mais personalizado, infelizmente não poderia aceitar isso
 porque você também disse que faz as coisas para ser produtivo.

Bom, aqui eu noto uma contradição sua, afinal independente da forma, o 
seu script também vai estar desatualizado no seu

Re: [pgbr-geral] Sugestão de uso

[Fabiano Machado Dias]

Boa noite a todos,

Estou chegando agora na discussão, mas posso falar sobre o tema, afinal 
criamos um ERP desta maneira, quem quiser pode conferir nos links abaixo.

O que posso dizer é que no nosso caso foi a escolha mais certa que já 
fizemos, você precisa ter muito cuidado com a documentação, 
principalmente se o número de desenvolvedores for grande.

Fizemos uso de PL/pgSQL direto, e hoje após quase 5 anos do cliente 
piloto posso te dizer ficou acima do esperado.

Até hoje não tive problema de performance, o desenvolvimento é 
extremamente rápido, sem falar na questão da segurança e confiança nas 
transações!

Na época lembro que muita gente falava que era loucura fazer desse 
jeito, e pelo que vi tem vários colegas da lista que pensam assim, o que 
posso dizer é que gostaria de ter enlouquecido bem antes, na época que 
segui o tal modelo 3 camadas e queria que minha aplicação fosse multi banco!

Bom é só a minha humilde opinião, se precisar de alguma dica fique a 
vontade para perguntar, apesar do foco do seu sistema ser diferente acho 
que é a mesma idéia!

Um grande abraço,
Fabiano Machado Dias




http://www.4linux.com.br/noticias/2010/PostgreSQL/PGCon2009
http://pgbr.postgresql.org.br/2009/palestras/aud2/ERP.pdf (Estava 
funcionando, quem quiser pode me pedir a palestra que eu envio)
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Estrutura de banco de dados fornecido por empresa terceirizada. Erros absurdos no meu ver, estou certo?

[Fabiano Machado Dias]

Em 14/6/2011 08:10, Leandro DUTRA escreveu:

2011/6/13 Fabiano Machado Diasfabi...@wolaksistemas.com.br:

Trabalho com sistemas ERP e posso te dizer que é impossível hoje em dia, uma
empresa de médio-grande porte colocar as suas operações em uma contingência
manual, pode me dar todos os argumentos do mundo, atualmente com NFe, Sped,
FCont, e-Lalur, etc é vital que os sistemas estejam sempre online.

Pois é… mas isso, em si, é um absurdo.

Primeiro, porque decorre de um excesso de burocracia e complexidade da
legislação.  Conheci um livreiro em Lausanne que nem pagava imposto:
ele simplesmente somava as faturas, e sempre dava abaixo do limite
mínimo para pagamento.  Aqui…?
Concordo, aqui temos a pior, ou uma das piores legislações do mundo. É 
imposto pra tudo e o pior é que as vezes nem os fiscais sabem fazer 
certo
Não foi nem 1 ou 2 vezes que vi fiscais e consultores baterem cabeça, é 
de confundir mesmo!



Segundo, o governo exige informatização sem ter viabilizado o uso de
sistemas livres, impondo um custo indevido aos negócios.  E essa
inviabilidade tem dois aspectos: por um lado, o uso de sistemas livres
no governo tem recuado (por exemplo, Câmara dos Deputados e Metrô de
SP regrediram de ODF para MS Office); por outro, o ensino continua
péssimo, o que tende a perpetuar a pirataria de Microsoft.
Sou a favor de sistemas livres mas quando falamos de sistema de gestão é 
raro ver um pacote livre vingar nas empresas, não estou falando de 
planilhas, documentos etc e sim do sistema gerencial (ERP), já vi várias 
iniciativas mas acho que isso não depende do governo, é uma área 
complicada. A questão do ensino nem se fala, está cada vez pior, parece 
que os professores fingem que ensinam e os alunos fingem que aprendem!!!





E isso é uma coisa boa a meu ver, se não quebrasse nunca o paradigma ainda
teríamos eleições com cédula (apesar de achar o nosso sistema falho),

Eleições com cédulas são as únicas seguras, até hoje.  Nem o mínimo de
segurança temos, que seria a votação eletrônica mas com impressão e
conferência pelo eleitor obrigatórias.
Como mencionei acho o nosso sistema falho, o que não quer dizer que não 
se possa realizar uma automação na contagem com a cédula física, foi só 
um exemplo, talvez não o melhor.



entregaríamos o IR em formulário

Seria melhor que ter de usar um programa proprietário.
Daí não né! Você entregou a sua em formulário nos anos anteriores só 
porque o sistema era proprietário? Aliás nem sabia que era, proprietário 
de quem? Quem desenvolve, não é a Serpro? A Serpro não é Serviço 
Federal de Processamento de Dados 
http://www.google.com/custom?q=Servi%E7o+Federal+de+Processamento+de+Dadossa=Searchclient=pub-6895347663279881forid=1channel=1024512873ie=ISO-8859-1oe=ISO-8859-1cof=GALT%3A%2300CC00%3BGL%3A1%3BDIV%3A%23FF%3BVLC%3A663399%3BAH%3Acenter%3BBGC%3AFF%3BLBGC%3AFF%3BALC%3A0033FF%3BLC%3A0033FF%3BT%3A00%3BGFNT%3AFF%3BGIMP%3AFF%3BLH%3A88%3BLW%3A293%3BL%3Ahttp%3A%2F%2Fwww.siglas.com.br%2Fimages%2Fsiglas.gif%3BS%3Ahttp%3A%2F%2Fwww.siglas.com.br%3BFORID%3A1%3Bhl=en 
? Então seria de propriedade do governo né?


Aliás daqui a alguns anos, com o sistema Hárpia [1], SPED [2] e o CCS 
[3] nem vamos precisar preencher a declaração, o governo ira ter todos 
os dados, só iremos conferir se o nosso nome e endereço está certo e já 
era!!! rsrs





pagaríamos as contas só no balcão do caixa

Non sequitur.


DDA, Internet Banking, Débito Automático, onde está a falácia? rsrs



Empresa com 2 mil funcionário existiam antes sim, mas existia um setor
inteiro só para fazer a folha de pagamento, outro só para o financeiro, sem
contar o fiscal e o contábil

Já pensaram que, em países com mão de obra mal remunerada como o
nosso, uma das causas de desemprego e da baixa remuneração é que o
fracasso das políticas educacional, fiscal e normativa faz sair mais
barato automatizar que empregar?
Não era diferente antes, tem emprego pra quem é capacitado, o problema 
aqui é outro como você mesmo falou.





hoje em dia é cada vez mais raro encontrar
alguém que saiba, fazer as coisas no papel.

E isso é péssimo… as empresas, na prática, não sabem funcionar sem
fornecedores de sistemas, geralmente proprietários.  Se ao menos
soubessem o que acontece, seria viável, por exemplo, trocar de
sistemas.
Concordo, mas o que vejo é cada vez mais as pessoas estão ficando 
preguiçosas, neste momento estou dando treinamento em 3 empresas e vejo 
isso na prática, ninguém quer entender o processo, todo mundo quer que 
os sistemas resolvam os problemas sem nem sequer entender a causa do mesmo.


E isso está acontecendo na sociedade como um todo, a maioria das pessoas 
não quer entender como as coisas funcionam, só querem que funcionem, o 
que é terrível, afinal é a próxima geração que irá nos sustentar!!! kkk


Abração,

Fabiano Machado Dias

[1] 
http://www.harpiaonline.com.br/harpia/index.php?option=com_contentview=articleid=1Itemid=8

[2] http://www1.receita.fazenda.gov.br/sobre-o

Re: [pgbr-geral] Você esteve no PGCon 2009?

[Fabiano Machado Dias]

Tem o Euler e atrás do Euler eu acho que é o Roberto Mello, atrás do 
Roberto o gordo de camisa listrada é o Eduardo Wolak e do lado dele de 
camiseta branca sou eu Fabiano Machado Dias!!


É isso aí!

Abraço,
Fabiano

Em 25/5/2011 16:59, Fábio Telles Rodriguez escreveu:

Para quem não está enchergando direito, tem uma foto melhor:

http://pgbr.postgresql.org.br/2009/img/Todos_editado.JPG



Em 25 de maio de 2011 16:53, Leandro DUTRA 
leandro.gfc.du...@gmail.com mailto:leandro.gfc.du...@gmail.com 
escreveu:


2011/5/25 Fábio Telles Rodriguez fabio.tel...@gmail.com
mailto:fabio.tel...@gmail.com:
 Diga onde você está na foto... para que eu anote por lá!

Engraçado, o Yahoo! fala para usar o botão para acrescentar alguém,
mas não achei o tal botão.

De qualquer maneira, eu estava ao lado da fotógrafa, minha digníssima.
 Mas meu filho me representou… Felipe Sakama Faria Dutra.



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




--
Atenciosamente,
Fábio Telles Rodriguez
blog: http://www.midstorm.org/~telles/ 
http://www.midstorm.org/%7Etelles/
e-mail / gtalk / MSN: fabio.tel...@gmail.com 
mailto:fabio.tel...@gmail.com

Skype: fabio_telles


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


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

Re: [pgbr-geral] Estrutura de banco de dados fornecido por empresa terceirizada. Erros absurdos no meu ver, estou certo?

[Fabiano Machado Dias]

Estava revendo a lista quando me deparei com essa questão, apesar de 
estar atrasado na discussão vou colocar a minha opinião. (Até rimou!!! 
rsrsrs)


Trabalho com sistemas ERP e posso te dizer que é impossível hoje em dia, 
uma empresa de médio-grande porte colocar as suas operações em uma 
contingência manual, pode me dar todos os argumentos do mundo, 
atualmente com NFe, Sped, FCont, e-Lalur, etc é vital que os sistemas 
estejam sempre online.


Nem o governo aceita essa desculpa porque você só pode emitir uma NFe em 
contigência se os servidores deles pararem, ou seja meu amigo, ficou 
sem net, sem sistema, sem luz, te vira! rsrs


E isso é uma coisa boa a meu ver, se não quebrasse nunca o paradigma 
ainda teríamos eleições com cédula (apesar de achar o nosso sistema 
falho), entregaríamos o IR em formulário, pagaríamos as contas só no 
balcão do caixa e por aí vai!


Empresa com 2 mil funcionário existiam antes sim, mas existia um setor 
inteiro só para fazer a folha de pagamento, outro só para o financeiro, 
sem contar o fiscal e o contábil, hoje em dia é cada vez mais raro 
encontrar alguém que saiba, fazer as coisas no papel.


Concordo que medidas devem ser tomadas para que tudo isso funcione, 
escolha do software, fornecedora, redundância, etc, mas em pleno 2011 
querer que uma empresa funcione como funcionava a meio século atrás é 
ter uma visão muito estreita da realidade.


Na teoria (ah a teoria, como é bonita) seria ótimo que pudéssemos ter 
essa segurança, mas na realidade (putz, tem a realidade) é impossível.


Abração a todos!

Fabiano Machado Dias



Em 27/5/2011 12:06, Fabrízio de Royes Mello escreveu:


Em 27 de maio de 2011 11:52, Guilherme Carvalho desenvolvedor.net 
http://desenvolvedor.net@gmail.com http://gmail.com escreveu:


Como rodar uma folha de pagamentos por operações não
informatizadas tendo mais de 2 mil funcionários?

Acho meio complicado, para não dizer impossível.


Complicado sim, impossível não... lembre-se que empresas grandes ( 2k 
funcionarios) existem desde antes dos computadores...


--
Fabrízio de Royes Mello
 Blog sobre TI: http://fabriziomello.blogspot.com
 Perfil Linkedin: http://br.linkedin.com/in/fabriziomello


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


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

Re: [pgbr-geral] Implantacao e Suporte

[Fabiano Machado Dias]

Em 6/4/2011 15:16, Leandro DUTRA escreveu:
 2011/4/6 CLAUDIO VIANAcoelhovi...@gmail.com:
   Alguém da comunidade poderia me sugerir algumas empresas para
 Implantação e Suporte do PostGre e  Migração de Dados do Banco Oracle para
 PostGre.
 Não conheço PostGre.  Esta lista é sobre PostgreSQL — se for o caso,
 vêm à mente a Dextra, a PgOpen e a 4Linux, não necessariamente nessa
 ordem.


Tá loco, só faltou o tacape!!! Depois ainda reclamam porque a comunidade 
dev está se esvaziando, com uma recepção destas quem da geral vai ter 
coragem de postar algo lá!!!

Cláudio a forma correta é Postgres ou PostreSQL, mas respondendo a sua 
pergunta conheço a Dextra e a 4Linux

Abraço,
Fabiano Machado Dias
___
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 Transações Em Postgres

[Fabiano Machado Dias]

Não precisa, pode ser dentro da função e dentro dessa função você pode 
chamar outras funções.


Usamos isso direto no nosso ERP

Exemplo:

CREATE OR REPLACE FUNCTION fnc.ajustecusto()
  RETURNS void AS
$BODY$
DECLARE
rNotafiscalentrada_item RECORD;
rNfei   RECORD;
BEGIN
FOR rNotafiscalentrada_item IN SELECT * FROM notafiscalentrada_item 
ORDER BY pknotafiscalentrada_item

LOOP
SELECT INTO rNfei 
(fnc.notafiscalentrada_item_calcular(rNotafiscalentrada_item.fknotafiscalentrada,rNotafiscalentrada_item.pknotafiscalentrada_item)).*;

UPDATE notafiscalentrada_item SET
valorunitariocusto = COALESCE(rNfei.valorunitariocusto,0),
demonstrativocalculocusto = rNfei.demonstrativocalculocusto
WHERE pknotafiscalentrada_item = 
rNotafiscalentrada_item.pknotafiscalentrada_item;

END LOOP;
END;
$BODY$
  LANGUAGE 'plpgsql' VOLATILE
ALTER FUNCTION fnc.ajustecusto() OWNER TO postgres;


Se for de interesse dá uma olhada nesse link, tem vários exemplos 
semelhantes


http://pgbr.postgresql.org.br/2009/palestras/aud2/ERP.pdf
http://www.4linux.com.br/noticias/2010/PostgreSQL/PGCon2009


Abraço,
Fabiano Machado Dias



Em 17/3/2011 15:16, izana souza torres escreveu:
Blz..então cada função seria uma transação ?? só q dentro da função 
que estou trabalhando não posso utilizar os comando COMMIT ou ROLLBACK 
explicitamente..




Logo o q estou entendo pelo o q os nobre colegas estão dizendo é o 
seguinte..



Imagine um código Java = E nele que vou trantar o COMMIT E ROLLBACKP 
falando grosseirament



exemplo;

try {

stmt.execute(select fecharCaixa()); // aqui ele chama a função fechar 
caixa

conn.commit()  // aqui ele comita caso tudo ok

}catch(Exception e){
  conn.rollback() // caso algum problema na hora de feixar o caixa
}


OU seja o que vcs estão tentando me dizer é que é em nivel de 
aplicação que eu vou utilizar o Comando commit e rollback

por exemplo..


Em 17 de março de 2011 12:48, Rogério Bassete 
roge...@microwork.inf.br mailto:roge...@microwork.inf.br escreveu:



Sim,
Como você falou, elas podem fazer para de uma transação quando
chamada
dentro de uma.
Mas teria como vc me dar um exemplo prático ?

Izana,

begin;
insert into foo values ('teste','teste2');
update foo set campo1 = 'teste3' where id = 3;
-- chama a sua função.
select funcao_baixa_estoque();
select funcao_gera_log();
commit;

Rogério Bassete

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



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


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

Re: [pgbr-geral] O PG simplesmente não inicia

[Fabiano Machado Dias]

Pare o serviço do Postgres, mova o arquivo postmaster.pid para outra 
pasta e inicie o serviço novamente.


Abraço,
Fabiano

Em 10/3/2011 11:18, Marcelo Silva (IG) escreveu:
Pessoal, até ontem estava tudo bem... hoje (10/03/11) o postgres 8.4 
simplesmente insiste em não iniciar o serviço.

Estou com Win7
Tento dar um restart mas ele simplesmente fica pensando e não 
inicia... e o pior, não dá nenhum erro especifico, ele só me manda dar 
o seguinte comando: NET HELPMSG 3521.

Dei esse comando no prompt mas não me mostra nada...
Como é maquina de desenvolvimento eu retirei e instalei o PG denovo, e 
nada adiantou.

Esse windows tem cada uma...
Alguém pode imaginar ou dar alguma pista do que possa ser?

A unica coisa que fiz de diferente esses dias, foi instalar o pacote 
de Codecs para assistir video (25781_k_lite_mega_codec_pack_700) será 
que ele deu algum conflito com o PG? não é possivel...

Marcelo Silva
---


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


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

Re: [pgbr-geral] O PG simplesmente não inicia

[Fabiano Machado Dias]

Porque você está rodando num Windows, se fosse num Linux nunca ia ter 
esse problema!!! rsrsrs!


Pelo que puder ver, parece que o Windows não consegue atualizar o número 
do processo, daí ele entra numa espécie de loop, tentando iniciar um 
processo que não existe mais.


Coisas de Microsoft!

Abraço,
Fabiano Machado Dias



Em 10/3/2011 11:35, Marcelo Silva (IG) escreveu:

Na mosca Fabiano... deu certo.
Sabe dizer por que isso acontece?
Marcelo Silva

*From:* Fabiano Machado Dias mailto:fabi...@wolaksistemas.com.br
*Sent:* Thursday, March 10, 2011 11:28 AM
*To:* pgbr-geral@listas.postgresql.org.br 
mailto:pgbr-geral@listas.postgresql.org.br

*Subject:* Re: [pgbr-geral] O PG simplesmente não inicia
Pare o serviço do Postgres, mova o arquivo postmaster.pid para outra 
pasta e inicie o serviço novamente.


Abraço,
Fabiano

Em 10/3/2011 11:18, Marcelo Silva (IG) escreveu:
Pessoal, até ontem estava tudo bem... hoje (10/03/11) o postgres 8.4 
simplesmente insiste em não iniciar o serviço.

Estou com Win7
Tento dar um restart mas ele simplesmente fica pensando e não 
inicia... e o pior, não dá nenhum erro especifico, ele só me manda 
dar o seguinte comando: NET HELPMSG 3521.

Dei esse comando no prompt mas não me mostra nada...
Como é maquina de desenvolvimento eu retirei e instalei o PG denovo, 
e nada adiantou.

Esse windows tem cada uma...
Alguém pode imaginar ou dar alguma pista do que possa ser?

A unica coisa que fiz de diferente esses dias, foi instalar o pacote 
de Codecs para assistir video (25781_k_lite_mega_codec_pack_700) será 
que ele deu algum conflito com o PG? não é possivel...

Marcelo Silva
---


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



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


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


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

Re: [pgbr-geral] O PG simplesmente não inicia

[Fabiano Machado Dias]

Talvez, mas me lembro que foi uma das primeiras coisas que verifiquei 
quando tive esse problema, no meu caso as permissões estavam ok, só 
resolveu quando movi o arquivo.

Mas como disse antes, se tratando de MS não duvido que aconteça em 
diferentes cenários.

Abraço,
Fabiano Machado Dias


Em 10/3/2011 12:07, Gustavo Garay escreveu:

 Porque você está rodando num Windows, se fosse num Linux nunca ia ter esse 
 problema!!! rsrsrs!
 Pelo que puder ver, parece que o Windows não consegue atualizar o número do 
 processo, daí ele entra numa espécie de loop, tentando iniciar umprocesso 
 que não existe mais.
 Coisas de Microsoft!
 Mas bien parece problema de persmiso, x alguna razon desconocida, el 
 archivo postmaster.pid pierde los permiso del dueño de servicio de postgres, 
 pasando a pertenecer al Administrador

 Gustavo






 Em 10/3/2011 11:35, Marcelo Silva (IG) escreveu:




 Na mosca Fabiano... deu certo.

 Sabe dizer por que isso acontece?


 Marcelo Silva
 




 From: Fabiano Machado Dias
 Sent: Thursday, March 10, 2011 11:28 AM
 To: pgbr-geral@listas.postgresql.org.br
 Subject: Re: [pgbr-geral] O PG simplesmente não inicia

 Pare o serviço do Postgres, mova o arquivo postmaster.pid para outra pasta e 
 inicie o serviço novamente.

 Abraço,
 Fabiano

 Em 10/3/2011 11:18, Marcelo Silva (IG) escreveu:




 Pessoal, até ontem estava tudo bem... hoje (10/03/11) o postgres 8.4 
 simplesmente insiste em não iniciar o serviço.
 Estou com Win7
 Tento dar um restart mas ele simplesmente fica pensando e não inicia... e o 
 pior, não dá nenhum erro especifico, ele só me manda dar o seguinte comando: 
 NET HELPMSG 3521.

 Dei esse comando no prompt mas não me mostra nada...

 Como é maquina de desenvolvimento eu retirei e instalei o PG denovo, e nada 
 adiantou.

 Esse windows tem cada uma...

 Alguém pode imaginar ou dar alguma pista do que possa ser?

 A unica coisa que fiz de diferente esses dias, foi instalar o pacote de 
 Codecs para assistir video (25781_k_lite_mega_codec_pack_700) será que ele 
 deu algum conflito com o PG? não é possivel...


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



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

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


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

Re: [pgbr-geral] O PG simplesmente não inicia

[Fabiano Machado Dias]

Exatamente, mas só vi dar problema até hoje no Windows, não é a primeira 
vez que isso aparece na lista e sempre que ocorreu comigo foi nesse sistema.


Abraço,
Fabiano Machado Dias



O postmaster.pid não é uma peculariedade de sistema X ou Y. O 
postmaster o cria durante a inicialização, e se o mesmo não for 
desligado corretamente, há grandes chances de o arquivo permanecer, 
como foi o caso.


2011/3/10 Marcelo Silva (IG) marc...@ig.com.br 
mailto:marc...@ig.com.br


Seja lá o que for, deletando o pid deu certo, em se tratando de
windows é
melhor não tentar entender rsrsrs...
Sou de SP e tomo conta de um servidor que está em sorocaba, tudo
via VNC...
meu, antes era novell com clipper de outro cara... que dor de
cabeça era,
depois que coloquei Delphi (nos clientes) + Linux, nem parece que
existe
maquina lá... nunca mais tive problemas, é um Ubuntu 8.4 ainda...
e não
pretendo mexer tão cedo, rsrsrs...


Mais uma vez, valeu a ajuda...


Marcelo Silva





-Mensagem Original-
From: Fabiano Machado Dias
Sent: Thursday, March 10, 2011 12:19 PM
To: Comunidade PostgreSQL Brasileira
Subject: Re: [pgbr-geral] O PG simplesmente não inicia

Talvez, mas me lembro que foi uma das primeiras coisas que verifiquei
quando tive esse problema, no meu caso as permissões estavam ok, só
resolveu quando movi o arquivo.

Mas como disse antes, se tratando de MS não duvido que aconteça em
diferentes cenários.

Abraço,
Fabiano Machado Dias


Em 10/3/2011 12:07, Gustavo Garay escreveu:

 Porque você está rodando num Windows, se fosse num Linux nunca
ia ter
 esse problema!!! rsrsrs!
 Pelo que puder ver, parece que o Windows não consegue atualizar
o número
 do processo, daí ele entra numa espécie de loop, tentando iniciar
 umprocesso que não existe mais.
 Coisas de Microsoft!
 Mas bien parece problema de persmiso, x alguna razon
desconocida, el
 archivo postmaster.pid pierde los permiso del dueño de servicio de
 postgres, pasando a pertenecer al Administrador

 Gustavo






 Em 10/3/2011 11:35, Marcelo Silva (IG) escreveu:




 Na mosca Fabiano... deu certo.

 Sabe dizer por que isso acontece?


 Marcelo Silva
 




 From: Fabiano Machado Dias
 Sent: Thursday, March 10, 2011 11:28 AM
 To: pgbr-geral@listas.postgresql.org.br
mailto:pgbr-geral@listas.postgresql.org.br
 Subject: Re: [pgbr-geral] O PG simplesmente não inicia

 Pare o serviço do Postgres, mova o arquivo postmaster.pid para
outra pasta
 e inicie o serviço novamente.

 Abraço,
 Fabiano

 Em 10/3/2011 11:18, Marcelo Silva (IG) escreveu:




 Pessoal, até ontem estava tudo bem... hoje (10/03/11) o postgres 8.4
 simplesmente insiste em não iniciar o serviço.
 Estou com Win7
 Tento dar um restart mas ele simplesmente fica pensando e não
inicia... e
 o pior, não dá nenhum erro especifico, ele só me manda dar o
seguinte
 comando: NET HELPMSG 3521.

 Dei esse comando no prompt mas não me mostra nada...

 Como é maquina de desenvolvimento eu retirei e instalei o PG
denovo, e
 nada adiantou.

 Esse windows tem cada uma...

 Alguém pode imaginar ou dar alguma pista do que possa ser?

 A unica coisa que fiz de diferente esses dias, foi instalar o
pacote de
 Codecs para assistir video (25781_k_lite_mega_codec_pack_700)
será que ele
 deu algum conflito com o PG? não é possivel...


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



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

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

Re: [pgbr-geral] O PG simplesmente não inicia

[Fabiano Machado Dias]

Tranquilo, o importante é resolver o problema.

Abraço,
Fabiano Machado Dias

Bom, já enfrentei tal problema em máquinas Linux, há muito tempo. 
Assim como já ocorreram desligamentos indevidos em servidores Windows 
dos clientes em que esse problema não apareceu.

Só antes que digam, não estou defendendo Windows, foi só um comentário.

2011/3/10 Fabiano Machado Dias fabi...@wolaksistemas.com.br 
mailto:fabi...@wolaksistemas.com.br


Exatamente, mas só vi dar problema até hoje no Windows, não é a
primeira vez que isso aparece na lista e sempre que ocorreu comigo
foi nesse sistema.

Abraço,
Fabiano Machado Dias





O postmaster.pid não é uma peculariedade de sistema X ou Y. O
postmaster o cria durante a inicialização, e se o mesmo não for
desligado corretamente, há grandes chances de o arquivo
permanecer, como foi o caso.

2011/3/10 Marcelo Silva (IG) marc...@ig.com.br
mailto:marc...@ig.com.br

Seja lá o que for, deletando o pid deu certo, em se tratando
de windows é
melhor não tentar entender rsrsrs...
Sou de SP e tomo conta de um servidor que está em sorocaba,
tudo via VNC...
meu, antes era novell com clipper de outro cara... que dor de
cabeça era,
depois que coloquei Delphi (nos clientes) + Linux, nem parece
que existe
maquina lá... nunca mais tive problemas, é um Ubuntu 8.4
ainda... e não
pretendo mexer tão cedo, rsrsrs...


Mais uma vez, valeu a ajuda...


Marcelo Silva





-Mensagem Original-
From: Fabiano Machado Dias
Sent: Thursday, March 10, 2011 12:19 PM
To: Comunidade PostgreSQL Brasileira
Subject: Re: [pgbr-geral] O PG simplesmente não inicia

Talvez, mas me lembro que foi uma das primeiras coisas que
verifiquei
quando tive esse problema, no meu caso as permissões estavam
ok, só
resolveu quando movi o arquivo.

Mas como disse antes, se tratando de MS não duvido que
aconteça em
diferentes cenários.

Abraço,
Fabiano Machado Dias


Em 10/3/2011 12:07, Gustavo Garay escreveu:

 Porque você está rodando num Windows, se fosse num Linux
nunca ia ter
 esse problema!!! rsrsrs!
 Pelo que puder ver, parece que o Windows não consegue
atualizar o número
 do processo, daí ele entra numa espécie de loop, tentando
iniciar
 umprocesso que não existe mais.
 Coisas de Microsoft!
 Mas bien parece problema de persmiso, x alguna razon
desconocida, el
 archivo postmaster.pid pierde los permiso del dueño de
servicio de
 postgres, pasando a pertenecer al Administrador

 Gustavo






 Em 10/3/2011 11:35, Marcelo Silva (IG) escreveu:




 Na mosca Fabiano... deu certo.

 Sabe dizer por que isso acontece?


 Marcelo Silva
 




 From: Fabiano Machado Dias
 Sent: Thursday, March 10, 2011 11:28 AM
 To: pgbr-geral@listas.postgresql.org.br
mailto:pgbr-geral@listas.postgresql.org.br
 Subject: Re: [pgbr-geral] O PG simplesmente não inicia

 Pare o serviço do Postgres, mova o arquivo postmaster.pid
para outra pasta
 e inicie o serviço novamente.

 Abraço,
 Fabiano

 Em 10/3/2011 11:18, Marcelo Silva (IG) escreveu:




 Pessoal, até ontem estava tudo bem... hoje (10/03/11) o
postgres 8.4
 simplesmente insiste em não iniciar o serviço.
 Estou com Win7
 Tento dar um restart mas ele simplesmente fica pensando e
não inicia... e
 o pior, não dá nenhum erro especifico, ele só me manda dar
o seguinte
 comando: NET HELPMSG 3521.

 Dei esse comando no prompt mas não me mostra nada...

 Como é maquina de desenvolvimento eu retirei e instalei o
PG denovo, e
 nada adiantou.

 Esse windows tem cada uma...

 Alguém pode imaginar ou dar alguma pista do que possa ser?

 A unica coisa que fiz de diferente esses dias, foi instalar
o pacote de
 Codecs para assistir video
(25781_k_lite_mega_codec_pack_700) será que ele
 deu algum conflito com o PG? não é possivel...


 Marcelo Silva
 ---
 ___
 pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br
mailto:pgbr-geral@listas.postgresql.org.br

Re: [pgbr-geral] Como evitar autenticação trust?

[Fabiano Machado Dias]

Dá uma olhada nisso, não resolve todo o problema mas uma parte dele pelo 
menos.


http://www.enterprisedb.com/products-services-training/products/complementary-enterprisedb-products/pl/secure

Abraço,
Fabiano Machado Dias

Em 4/3/2011 00:44, Fabricio Srdic escreveu:

Boa noite a todos

Gostaria de agradeçer a todos que opinaram.

Não imaginei que causaria uma polêmica com essas proporções...

Pessoal, quando lançei a pergunta sobre a questão do trust na verdade 
tinha duas preocupações:


1 - Proteger o patrimônio intelectual;
2 - Proteger o sistema contra a pirataria;

A 2ª opção é possível contornar com sucesso. Mas a primeira parece que 
não é possível. O projeto de um banco de dados é algo muito valioso. O 
banco de dados é a parte mais importante de qualquer que seja o 
sistema. O modo como o banco é projetado, a lógica utilizada, os 
métodos utilizados para resolver os problemas de análise, tudo isso 
envolve muito investimento e pesquisa. Alguns podem achar loucura o 
que vou dizer, mas considero um projeto de banco de dados mais valioso 
do que qualquer código-fonte de qualquer aplicação que acesse esse 
mesmo banco de dados.


Como o meu propósito é criar um sistema com fins comerciais, e sendo 
um sistema comercializado em modo de concessão de licença de uso, 
surgiu uma preocupação de como proteger esse patrimônio intelectual. 
Como não estou vendendo o meu projeto, estou apenas concedendo a 
licença de uso deste, não é nada interessante ver esse patrimônio 
exposto dessa maneira. Fico com a sensação de vender um software e 
entregar os fontes para o usuário. Imagine, você comprar o windows e 
vir junto os fontes... Conheço casos na justiça em que softhouses 
processaram pessoas que contrataram os seus sistemas, cancelaram o 
serviço, então pegaram o banco de dados e contrataram um programador 
para desenvolver uma aplicação que acesse esse banco de dados.


Antes dar as caras novamente por aqui na discussão resolvi dar uma 
olhada nos outros SGDB's comerciais, e eles foram o Oracle e o DB2, os 
dois senhores dos SGDB's. Pude verificar que os dois tambem não 
oferecem autenticação a nível de banco, ou seja, novamente não é o DBA 
que dá a ultima palavra sobre quem pode ou não acessar o banco, é o 
administrador do servidor. Vendo que mesmo os SGDB's comerciais são 
dessa maneira, acho que fui infeliz ao fazer a pergunta que iniciou 
essa discussão. Talvez eu deveria ter sido mais claro nas minhas 
intenções. Peço desculpas.
O problema não é o Postgres ou o Firebird. A filosofia dos SGDB's em 
geral é assim.  Com relação aos SGDB's não há nada o que fazer.


Mas de qualquer forma creio que a minha preocupação com o projeto do 
banco é algo bastante válido. Tanto é que na Europa existe legislação 
específica para tratar de proteção de direitos dos autores de projetos 
de banco de dados.


Novamente agradeço a todos que participaram!




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

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

Re: [pgbr-geral] ENC: RES: Uso de memória pelo postgres

[Fabiano Machado Dias]

Primeiro, HD Sata de 5400 não dá né! Coloque SAS de 15k pelo menos!

Segundo, troque os SELECT IN por EXISTS ou encadeie novamente o SELECT 
para usar LEFT JOIN, outra coisa que você pode fazer é primeiro trazer 
os dados e depois aplicar as conversões.


Abraço,
Fabiano Machado Dias

Em 4/3/2011 07:55, Irineu Raymundo escreveu:

Como o Euler disse, fica muito difícil imaginar o que a sua rotina está fazendo. Se for 
um processo crítico para você,recomendo contratar uma consultoria para avaliar o 
problema. Podemos dar algumas dicas aqui, mas os seus problemaspodem começar na 
configuração do PostgreSQL, passando por problemas de modelagem e possivelmente de 
reescrita doprocedimento com o um todo.

Sem enxergar o processo como um todo, fica muito difícil lhe ajudar. Já fiz este tipo 
de trabalho para várias vezes esei como é difícil ajudar sem ter uma visão global 
do problema. Tenho certeza de que você vai encontrar ótimosprofissionais por aqui.

Agora, se você puder mostra todo o processo aqui, então poderemos lhe dar 
algumas idéias, claro.

--


Prezado Fábio,

Obrigado pela ajuda, vou seguir o teu conselho e sugerir uma consultoria para 
avaliar o problema.

De qualquer forma consegui levantar alguma informações,o problema se resume a 2 
comandos SQL.

abaixo segue os comandos.Poderia a falta de um índice mais apropriado causar 
essa demora toda na execução dele?

Os shared_buffers do postgres não tem valor de memória significativo alocada, o 
postgres tá dependendo totalmente do sistema operacional para o gerenciamento 
de memória.

Servidor: OS Linux RedHat Interprise 5,  2  HD's SATA 5200rpm fazendo raide 1, 
4GB RAM.
PostgreSQL 8.3 ,base com 19GB aproximadamente.

O processo problemático iniciou aproximadamente as 13:17 de ontem e terminou as 
15:04.

O Postgres usou 3,7 GB de RAM.

Foi alterado a  configuracao do PostgreSQL para reportar nos logs todo comando 
SQL cujo tempo de execucao ultrapesse 500ms.

Gerou 1.534 comandos SQL no log, indicando que esse processo executou 
aproximadamente 1.500 comandos SQL com tempo superior a 500ms. O log aponta que 
estes comandos se resumem a apenas 2 comandos SQL, um sendo executado 513 vezes 
e o outro 1019.

Essa tabela tem (ind_03_03_02_01_01) tem 840MB.

Os dois comandos SQL sao:
1019 vezes:
SELECT DISTINCT
CAST(array_to_string(ARRAY(SELECT op2.tamanho || '/' || 
CAST(SUM(op2.quantidade) AS VARCHAR)
 FROM senda.ind_03_03_02_01_01 op2
WHERE op2.tamanho  '' AND
  op2.remessa = op.remessa AND
  op2.cod_componente = 
op.cod_componente AND
  op2.cod_material = 
op.cod_material AND
  op2.cod_cor = op.cod_cor AND
 op2.cod_op IN
(SELECT op3.cod_op
   FROM 
senda.ind_03_03_02_01_02_a1 op3
  WHERE op3.remessa = 
op2.remessa AND
 op3.op_aux2 =0 AND
op3.usuario = '' AND
op3.sequencia_comp = 0)
 GROUP BY op2.remessa, 
op2.cod_componente, op2.cod_material, op2.cod_cor, op2.tamanho
 ORDER BY op2.remessa, 
op2.cod_componente, op2.cod_material, op2.cod_cor, op2.tamanho
  ), '   ') AS VARCHAR) AS grade
   FROM senda.ind_03_03_02_01_01 op
  WHERE op.tamanho  '' AND
op.remessa IN (SELECT op3.remessa
 FROM senda.ind_03_03_02_01_02_a1 op3
WHERE op3.remessa = op.remessa AND
  op3.op_aux2 = 0 AND
  op3.sequencia_comp = 0 AND
  op3.usuario =  '')  AND
op.cod_componente = '' AND
op.cod_material = '' AND
op.cod_cor = 0;

513 vezes:
SELECT  op.numero,
  op.quantidade
  FROM senda.ind_03_03_02_01_02 op
  WHERE op.remessa IN(SELECT op2.remessa
   FROM senda.ind_03_03_02_01_02_a1 op2
   WHERE op2.remessa = op.remessa
 AND op2.sequencia_comp = 54
 AND op2.op_aux2 = 392
 AND op2.usuario = 'adriel')
 AND op.cod_op IN
   (SELECT op2.cod_op
FROM senda.ind_03_03_02_01_02_a1 op2
WHERE op2.remessa = op.remessa AND
  op2.sequencia_comp = 54 AND
  op2.op_aux2 =392 AND
  op2.usuario = 'adriel')
order by numero;

Os explain analyze referente a ambos comandos:

Comando 1:
  Sort  (cost=3197917.93..3198379.07 rows=184457

Re: [pgbr-geral] ENC: RES: Uso de memória pelo postgres

[Fabiano Machado Dias]

E além da controvérsia quanto a segurança nunca vi em produção, só 
alguns testes.

Teoria é uma coisa, mas muitas vezes na prática é outra bem diferente.

Abraço,
Fabiano

Em 4/3/2011 14:20, Leandro DUTRA escreveu:
 2011/3/4 Fábio Telles Rodriguezfabio.tel...@gmail.com:
 Olha, olhando com mais profundidade... ainda existe um pouco de controvérsia
 quanto a segurança disso. Estive lendo alguns trabalhos e a forma como os
 sistemas de arquivos trabalham com eles ainda não é o ideal para bancos de
 dados.
 Referências?  Há sistemas de arquivos específicos para /flash/.  De qualquer
 maneira, pode não ser ideal, mas já é muito melhor que meios magnéticos.


 Sim, fica muito mais rápido, mas ainda há dúvidas sobre a
 confiabilidade.
 Que dúvidas?


 Vou citar aqui um trecho do livro do Gregory Smith:
 Que livro, de quando?


 While small, these are still effectively a write-back cache, with all the
 potential data corruption issues any such design has for database use (as
 discussed in detail later in this chapter). Some SSDs include a capacitor or
 similar battery backup mechanism to work around this issue
 Ou seja, é só assegurar‐se de comprar uma unidade que tenha o tal capacitor.


 the ones that do not may have very rare but still real corruption concerns.
 Como tem qualquer suporte físico.  Geralmente, mais do que unidades /flash/.

   Esse livro levou em consideração as unidades SAS (SCSI serial), feitas
 para confiabilidade?  O custo ainda é alto, mas é tudo uma questão de
 balanceamento na montagem do sistema e adequação ao uso.



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

Re: [pgbr-geral] RAID 10

[Fabiano Machado Dias]

  Eu faria diferente, colocaria SO + PG (dados) no array 1 e log de 
transação no array 2.

Att,
Fabiano Machado Dias

Em 9/8/2010 10:50, Sebastian SWC escreveu:
 Pessoal,

 Minha aplicação é OLTP. Tenho um servidor com 8 discos rodando em 2
 arrays de 4 discos (ambos em raid 1+0). uso estes discos para o
 sistema operacional (array 1), log de transação (array 1) e postgresql
 (array 2).

 Na experiência de vocês, o que vale mais a pena?
 1) criar um array em 1+0 com todos os discos?
 2) continuar utilizando  dessa forma?
 3) alguma outra idéia?

 Comento que estou tendo um gargalo no primeiro array. Em horário de
 pico, o atop mostra a atividade do disco em 101%...


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

Re: [pgbr-geral] Sugestão de servidor.

[Fabiano Machado Dias]

 Compra um Xeon Quad Core, mínimo de 8GB e no mínimo 2 HDs SAS de 15K 
para fazer RAID 1.


Lembrando que isso seria o básico, se tiver grana a coisa muda!

Abraço,
Fabiano Machado Dias



Em 5/8/2010 15:15, Alex Barbosa Ferreira escreveu:

Boa tarde!

a empresa em que trabalho decidiu fazer investimento num servidor para 
nosso banco de dados, diante desta situação gostaria de algumas 
sugestões de configuração.
Atualmente nosso banco de dados está com 50GB e um crescimento 
aproximado de 2% por semana.
O servidor atual é biprocessado Xeon com 4GB de memória e dois HD Sata 
com placa-mãe Intel sem unidade de backup.


Atenciosamente,

*Alex B. Ferreira*
*/Analista em Segurança da Informação/*



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


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

Re: [pgbr-geral] Res: Sugestão de servidor.

[Fabiano Machado Dias]

 Prefiro Intel, já tive problemas com AMD por causa do aquecimento. 
Lembrando que o seu gargalo é disco, gaste o seu dinheiro nele, depois 
memória e depois processador.


Recomendo dar uma olhada na palestra do Telles
http://www.slideshare.net/telles/discos-cia-em-postgresql

Abraço,
Fabiano Machado Dias

Em 5/8/2010 16:25, Alex Barbosa Ferreira escreveu:

Para banco de dados qual processador, um Intel Xeon ou AMD Opteron?
*Alex B. Ferreira*
*/Analista em Segurança da Informação/*



*De:* Nilson Chagas nilson.chagas.si...@gmail.com
*Para:* Comunidade PostgreSQL Brasileira 
pgbr-geral@listas.postgresql.org.br

*Enviadas:* Quinta-feira, 5 de Agosto de 2010 16:08:09
*Assunto:* Re: [pgbr-geral] Sugestão de servidor.

2010/8/5 Alex Barbosa Ferreira al...@yahoo.com.br 
mailto:al...@yahoo.com.br


Boa tarde!

a empresa em que trabalho decidiu fazer investimento num servidor
para nosso banco de dados, diante desta situação gostaria de
algumas sugestões de configuração.
Atualmente nosso banco de dados está com 50GB e um crescimento
aproximado de 2% por semana.
O servidor atual é biprocessado Xeon com 4GB de memória e dois HD
Sata com placa-mãe Intel sem unidade de backup.



Não sei qual o tamanho do investimento, mas um servidor com 8Gb e HD SAS
Uma mera opinião.

--
[]s
Nilson Chagas - Ubuntu User 25794 (Hospedagem com postgresql a partir 
de R$ 5,00)

---
Visite:
http://www.avozdoevangelho.com.br - Peça gratuitamente um curso Bíblico

Twitter: avozdoevangelhoTwitter: matrixspnet

http://www.amados.com.br
http://bbnradio.org - Ouça a rádio e faça gratuitamente um Curso 
Biblico On-Line





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


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

Re: [pgbr-geral] Divisão de módulos do ERP em Esqu emas...

[Wolak Sistemas - Fabiano Machado Dias]

Concordo com o Mozart,

Nós temos um ERP e te digo, coloca tudo em um único schema e faça um 
controle de acesso aos módulos através de uma tabela de controle.

A idéia de separar os módulos por schema, só vai te trazer dor de cabeça 
quando você precisar integrar os dados, e começar a escrever código que 
necessite de várias ligações.


Abraço,
Fabiano Machado Dias



Mozart Hasse escreveu:
 Olá Olavo,

 A divisão em schemas parece interessante porque realmente divide as tabelas 
 em grupos. À medida que seu modelo cresce (e nem precisa chegar nas 2000 
 tabelas, com 1000 já se tem problemas), o que costuma aparecer são tabelas 
 compartilhadas por diversos módulos. Não importa em que módulo você as 
 coloque, sempre terá quem interprete que ela deveria estar em outro lugar. 
 Pior ainda quando mudam seus requisitos e começam a sobrar motivos para 
 mudá-la de um módulo para o outro, gerando um retrabalho absurdo por um 
 benefício questionável.
 Mudar a tabela de lugar em visões de modelo dentro da sua ferramenta de 
 modelagem, contudo, é uma tarefa simples e sem consequências mais sérias, 
 pois você poderá colocar cópias dela em quantos modelos convier.
 Devido a isso, sou mais favorável a largar mão dessa história de misturar 
 schema com documentação e colocar todas as tabelas num schema só. Facilita 
 enormemente o desenvolvimento e montagem das consultas, além de facilitar 
 *muito* a manutenção.
 Talvez alguém cogite a idéia de controlar a segurança dos módulos por 
 esquema, porém acho pouco provável que um esquema assim atenda a qualquer 
 cliente por causa das tabelas compartilhadas e potenciais problemas quando 
 uma tabela mudar de módulo.

 Minha sugestão, portanto, é: use um schema só e seja feliz.

 Atenciosamente,

 Mozart Hasse



 From: C.P.D. - T.I. MoRHena c...@morenarh.com.br
 To: pgbr-geral@listas.postgresql.org.br

  Estou desenvolvendo um ERP e vou comercializá-lo em módulos. Em
 virtude de disponibilizar em módulos, gostaria de separar as tabelas do
 banco de dados por módulo. Seria adequado o uso de esquema neste caso ?
 Ou seja no banco de dados teria esquema como: vendas, faturamento,
 financeiro e para cada esquema suas respectivas tabelas. É uma boa
 prática usar deste artifício ?

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

   

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

Re: [pgbr-geral] PROBLEMAS DE PERFORMANCE

[Wolak Sistemas - Fabiano Machado Dias]

Boa tarde,

Concordo com o Telles, rodar um banco de dados em um ambiente
virtualizado no  uma boa idia a no ser para fins de testes e olhe
l!

Recomendo que voc leia atentamente esse artigo [1] e configure melhor
o seu postgresql.conf

Neste outro link [2] voc pode colocar o valor em GB que ele te d o
valor correto em bytes.

Para o valor de shmmax voc pode utilizar o valor calculado pelo site,
e para o shmall pegue o mesmo valor (ou o que voc quer especificar) e
divida por 4096.

Por exemplo: 

6 GB = 6442450944 bytes
6442450944 / 4096 = 1572864

ento


kernel.shmmax = 6442450944
kernel.shmall = 1572864

shared_buffers deve ser igual ou menor que o valor de kernel.shmmax

No lembro se na 8.1 os valores j so em MB, mas de qualquer forma
atualize a sua verso para a 8.4

Outras coisas que voc pode alterar de cara so esses:

work_mem - Cuidado com valores grandes, leia o artigo que voc vai
enteder
max_stack_depth - utilize o "ulimit - s" e veja o valor retonado, faa
testes mas nunca ultrapasse o valor
vaccum_cost_delay - habilite porm o valor vai depender bastante da
aplicao
commit_delay - idem vaccum_cost_delay 
random_page_cost = 2


[1] -
http://www.pgcon.org/2008/schedule/attachments/44_annotated_gucs_draft1.pdf
[2] - http://www.easycalculation.com/bandwidth-calculator.php

Abrao,
Fabiano Machado Dias


sebastiao fidencio escreveu:

  Pessoal Bom dia, estou enviando esse email, porquanto estou com
srio problemas de performance eu meu banco de dados. Segue meu cenrio:
  
  servidores fisicos
  
  2 servidores- DLG 160 com 38 GB de ram cada um, trabalhando em
cluster.. (hd dos servidres e de 146GB) - cada mquina fisica tem 2
CPU quad..da intel
  storage com 8 discos de 400 gb, trabalhando em raid.
  
  
  Sistema operacional instalado nos Servidores fisicos: VMWARE
ENTERPRISE ESX 4.0
  
  
  Tenho umas 13 mquinas virtuais criadas entre windows e linux,
Entretanto o servidor de banco de dados(maquina virtual)que de fato 
o postgresql 8.1.3 com a seguinte configurao:
  
  6 (cpu's)
  16GB de ram
  150GB na partio /dados onde est montado o cluster do banco de
dados de produo.
  10 GB onde est instalado a distribuio SUSE Linux Enterprise
11 64bits
  
  
  
  Problema: 
  
  
  Acontece que, pessoal comea usar o sistema pela parte da manh,
e por volta de 10:00hrs da manho o ERP comea a ficar bastante lento
at chegar o ponto de travar, e percebo que quanto mais recurso
disponibilizo para o servidor de sgbd, mais ele consome, poxa..na tem
hardware que de conta disso. as consultas, a CPu e memoria vai para o
ultimo estagio, e toda vez tem q ficar reiniciando o sgbd, j segui
alguns conselhos para realizar tunnig no sgbd, mas no deu certo..,
gostaria da opinio de vocs o que eu tenho que fazer para resolver
esse problema.
  
  segue o link para vocs verem minhas conf's
  
  postgresql.conf
  http://200.175.138.130/postgresql.conf
  
  
  System V: (configurao defaul que veio, eu nem mexi em nada)
  
  kernel.shmmax = 18446744073709551615
kernel.shmall = 1152921504606846720
kernel.shmmni = 4096
  
  
  
  
  
  estado da maquina agora sem problemas: (porem a qualquer momento
ela pode apresenta problemas, principalmente quando os usuarios racam
relatorios pesados)..
  
  a rede hoje tem cerca de 150 usuarios ativos no sistema.
  
  
  
  uso de memoria
  =
  dberp:/dados/pgsql # cat /proc/meminfo
MemTotal: 16307396 kB
MemFree: 1711440 kB
Buffers: 23724 kB
Cached: 4221676 kB
SwapCached: 80676 kB
Active: 4742244 kB
Inactive: 1533132 kB
SwapTotal: 1044216 kB
SwapFree: 592144 kB
Dirty: 1012 kB
Writeback: 0 kB
AnonPages: 1954908 kB
Mapped: 1075736 kB
Slab: 70516 kB
SReclaimable: 34456 kB
SUnreclaim: 36060 kB
PageTables: 201260 kB
NFS_Unstable: 0 kB
Bounce: 0 kB
WritebackTmp: 0 kB
CommitLimit: 9197912 kB
Committed_AS: 3784748 kB
VmallocTotal: 34359738367 kB
VmallocUsed: 306132 kB
VmallocChunk: 34359431799 kB
HugePages_Total: 0
HugePages_Free: 0
HugePages_Rsvd: 0
HugePages_Surp: 0
Hugepagesize: 2048 kB
DirectMap4k: 10240 kB
DirectMap2M: 16766976 kB
dberp:/dados/pgsql #
==
  
  
  
  
  cpu
  ===
  top - 11:55:46 up 21:26, 2 users, load average: 0.71, 0.40,
2.34
Tasks: 197 total, 1 running, 194 sleeping, 2 stopped, 0 zombie
Cpu0 : 2.2%us, 0.8%sy, 0.0%ni, 95.8%id, 1.3%wa, 0.0%hi, 0.0%si,
0.0%st
Cpu1 : 14.8%us, 1.7%sy, 0.0%ni, 71.9%id, 11.3%wa, 0.0%hi, 0.1%si,
0.0%st
Cpu2 : 1.5%us, 0.8%sy, 0.0%ni, 97.2%id, 0.6%wa, 0.0%hi, 0.0%si,
0.0%st
Cpu3 : 0.3%us, 0.7%sy, 0.0%ni, 98.6%id, 0.3%wa, 0.0%hi, 0.0%si,
0.0%st
Cpu4 : 0.2%us, 0.7%sy, 0.0%ni, 98.9%id, 0.2%wa, 0.0%hi, 0.0%si,
0.0%st
Cpu5 : 0.2%us, 0.6%sy, 0.0%ni, 99.1%id, 0.1%wa, 0.0%hi, 0.0%si,
0.0%st
Mem: 16307396k total, 14723100k used, 1584296k free, 24536k buffers
Swap: 1044216k total, 451616k used, 59

Re: [pgbr-geral] PostGreSQL 8.4 Crystal Reports 10

[Wolak Sistemas - Fabiano Machado Dias]

Bom dia,

Eu uso o Crystal Reports com Postgresql a bastante tempo, no entanto
no utilizo a estrutura de tabelas dele, escrevo o SQL diretamente no
"Command" da conexo, assim o controle  maior e o desempenho melhora
bastante.

O SqlExpression trabalha o comando ali escrito como uma coluna do
relatrio, ento verifique o log e rode ele diretamente no Postgresql e
veja se o que o Crystal escreveu est de acordo com o que voc quer.

De qualquer forma vale a pena usar o "Command" pois ali voc  que
escreve o comando e tem controle sobre o que est sendo feito no banco,
eu pessoalmente nunca gostei de ferramentas que "montam o sql".

Abrao,
Fabiano Machado Dias



Edimar Rangel escreveu:
Bom dia a todos,
  
Utilizo o Crystal 10 \ ODBC \ PostGreSQL 8.4, e sempre que utilizo
SQLExpression, no editor do Crystal, ele trava, sem nenhum erro,
simplemente trava e tenho que finaliza-lo, isso s acontece quando
utilizo o postgre, possuo a mesma base de dados rodando no sql server
2005 e funciona normalmente.
  
Algum poderia me dar uma dica?
  
Atenciosamente,
  
Edimar Rangel
  

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




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

Re: [pgbr-geral] Sistema de Login para site de Intranet

[Wolak Sistemas - Fabiano Machado Dias]

M

tiago gomes tiagotecno...@gmail.com escreveu:

Obrigado Vinicius P., José C., Tiago A., Andre F. e JotaC., valeu pela
ajuda, não sabia que este fórum era tão sério e que os usuários fossem tão
interessados à divulgar o postgres.

Bom alguns me perguntaram como seria este site que quero fazer, pois bem ele
é assim:
*

*É um site intranet com controle de acesso de usuários de internet via
rádio. (Com aproximadamente 290 usuários)

*Terá somente 2 níveis de acesso (Admin e Usuario) no qual o Admin poderá
cadastrar, excluir e editar novos Usuários.

*Os Usuários terão acesso à net mas poderão ser bloqueados pelo número MAC
ou IP.

*Cada vez que o usuário se logar um relatório será criado mostrando a hora e
data que se logou, o n° MAC ou IP, talvez a hora que efetuou logout, e claro
o nome do usuário que se logou.

*Ao estar logado, o usuário terá uma mensagem de boas vindas com seu nome, a
hora e data. (ex: Bom Dia José, 05-11-2009)

* O Usuário terá a Opção de fazer a mudança de senha e login.

*( E o que eu acho mais dificil) O Administrador poderá enviar mensagens
para um usuário em especial.(Como um popup (para informar pendências de
pagamento ou datas comemorativas)

* O Administrador poderá bloquear o acesso de algum Usuário.*

**O Usuário Só poderá ter acesso à internet se estiver logado. (Este item
não é tão importante no meu caso)*







Em 20 de março de 2010 16:15, JotaComm jota.c...@gmail.com escreveu:

 Olá,

 Em 20 de março de 2010 01:26, tiago gomes tiagotecno...@gmail.comescreveu:

 Olá pessoal,


 Sou novo no Postgres e quero saber como se faz um sistema de login com
 níveis de acesso para um site intranet.


 Bem vindo ao PostgreSQL, você não vai se arrepender :)

 Sob o meu ponto de vista, o sistema de login e controle de acesso depende
 muito de qual é a regra de negócios e o que vai estar envolvido. Os usuários
 do sistema estarão mapeados em alguma tabela de usuário do banco? Vai ser um
 usuário padrão para todos os usuários? Os usuários terão níveis de permissão
 diferentes? Existe algum grupo de usuários que terão certos privilégios?

 Deixo a dica de não usar um superusuário para fazer as conexões entre o BD
 e a aplicação, use sempre um usuário regular (usuário que não é um
 superusuário).

 Também existe a questão se você vai deixar a regra de negócios dentro da
 aplicação ou dentro do BD? Acho que esta pergunta é interessante ser
 respondida já no começo, e sem meio termo, uma metade na aplicação e outra
 metade no BD.

 Você vai ter uma


 Eu sei faser em MySQL mas quero entrar no mundo Postgres.


 Desde já Obrigado.

 --
 tiagotecno...@globo.com
 Tiago Gomes de Oliveira
 Designer Gráfico
 (62)81252423
 Uruaçu - GO

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



 []s
 --
 JotaComm
 http://jotacomm.wordpress.com

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




-- 
Tiago Gomes de Oliveira
Designer Gráfico
(62)81252423
Uruaçu - GO

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

Re: [pgbr-geral] Otimizações Sistema/PostgreSQL

[Wolak Sistemas - Fabiano Machado Dias]

Use uma conexao permanente por usuario. Evite ficar criando varias conexoes, 
apesar de a teoria dizer que vc deve conectar, buscar e desconectar, na pratica 
isso gera um grande gargalo.

Abraco,
Fabiano Machado Dias

Pablo Sánchez phack...@gmail.com escreveu:

Caros,

Estamos com um pequeno, mas não muito grande, problema. Estamos
realizando a apresentação do sistema que desenvolvemos rodando em um
notebook. O problema é que ao pendurar 40 usuários simultâneos
acontecem algumas coisas meio estranbólicas. O sistema utiliza muitas
construções hierárquicas, ou seja, ele tem muitas estruturas em árvore
(eu pessoalmente acho que o gargalo começa aí, mas o outro analista
que está há 2 anos no projeto acha que não - só que vendo o código que
existe, aff maria, tem nem por onde começar a desfazer o macarrão
desorientado a objetos que foi criado antes de eu entrar nesse
projeto!).

Para praticamente tudo, ele inicia transações, inclusive para
consultas. Nisso, já tem um dos vários gargalos que temos que desfazer
(comecei por aí), afinal de contas, para consultas, transações são
indiferentes, não precisa dar um rollback nunca, então, é meio que
inútil fazer isso.

Outra coisa que estamos fazendo, só para as apresentações (afinal de
contas, o note onde está rodando o sistema não é nenhum servidor, né?)
é desativar o fsync.

Já andei vendo várias outras otimizações possíveis no postgres, que é
quem está realmente morrendo, mas não resolveu-se 100% ainda. Porque
eu afirmo que é o PG, e não o Apache? Simples, porque as mensagens de
erro são Desculpe, excedido o limite de conexões simultâneas -
colocamos para 80, e ainda assim E outra mensagem drástica foi
Postgres está desligando. Não eram essas as exatas palavras, eram as
mensagens do PG mesmo, repassadas ao PHP e então enviadas aos
navegadores. Terrível!

Já verifiquei uma coisa no código: é aberta apenas uma conexão por
requisição, ou seja, se temos 40 máquinas conectadas, 80 conexões
simultâneas permitidas, a princípio isso não deveria ser o problema.

Alguém tem alguma outra dica de otimização do PostgreSQL?

Outra, e mais importante: precisamos de uma ferramenta de
monitoramento do PostgreSQL, uma decente, preferencialmente gratuita,
ou pelo menos shareware para 30 dias. Alguém tem uma boa dica de
ferramenta?

-- 
=
Pablo Santiago Sánchez
phack...@gmail.com
(61) 9975-0883
http://www.sansis.com.br
Quidquid latine dictum sit, altum viditur
=
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Usando CPF/CNPJ como PK

[Wolak Sistemas - Fabiano Machado Dias]

Use uma pk artificial e seja feliz. Fuja de pks compostas, elas ainda vao te 
dar uma bela dor de cabeca.
Abraco

Joares Luis Dalorsoleta joa...@speedlinux.com.br escreveu:

Sugiro que se necessario adicione as primeiras posições antes do CNPJ
o codigo do estado (De acordo com o IBGE) e o codigo do municipio (de
acordo com o IBGE) talvez consiga algo mesclando essas informações com
o CNPJ.

at

Em 4 de março de 2010 13:28, Alexsander Rosa
alexsander.r...@gmail.com escreveu:
 Estou prestes a fazer uma reforma no meu ERP e uma das coisas que está me
 incomodando é o cadastro de pessoas. Não pude usar CPF/CNPJ como chave
 primária natural porque, conforme já foi dito aqui várias vezes, muitos
 clientes diferentes usam o mesmo CNPJ, especialmente órgãos públicos. Para
 dar um exemplo: temos um cliente que tem várias CENTENAS de clientes -- a
 imensa maioria, escolas da rede estadual -- com o mesmo CNPJ
 (92.941.681/0001-00), que segundo a Receita Federal está registrado em nome
 da Secretaria da Educação do RS.

 Uma possibilidade é usar uma chave composta, tipo CNPJ + chave extra onde
 esta chave extra tem NULL em todas as PF e quase todas as PJ. Quando uma PJ
 pertencer a mais de um cliente (órgãos públicos, universidades, etc), esta
 chave extra conterá um código (numérico? texto?) que identificará cada
 unidade. Para escolas, poderia ser um código tipo INEP, por exemplo. Em
 universidades poderia ser algum código que identifique o setor.

 Alguém tem alguma sugestão para isto?

 --
 Atenciosamente,
 Alexsander da Rosa
 Linux User #113925

 Extremismo na defesa da liberdade não é defeito.
 Moderação na busca por justiça não é virtude.
 -- Barry Goldwater

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





-- 
Atenciosamente
Joares Luís Dalorsoleta

Esta mensagem (incluíndo qualquer anexo) é dirigida apenas para o uso
do indivíduo ou da entidade a qual está endereçada e pode conter
informações privadas, proprietárias, privilegiadas, confidenciais que
podem servir como evidências sob as leis aplicáveis ou em processos
judiciais.
Caso você não seja o destinatário pretendido, você está aqui
notificado que qualquer uso, disseminação, distribuição, ou cópia
dessa comunicação é estritamente proibida. Se você recebeu essa
comunicação por engano, notifique-nos imediatamente por telefone, e
(i) destrua essa mensagem se for um facsimile ou (ii) exclua
imediatamente essa mensagem se esta for uma comunicação eletrônica.
Obrigado.

This message (including any attachments) is intended only for the use
of the individual or entity to which it is addressed and may contain
information that is non-public, proprietary, privileged, confidential,
and exempt from disclosure under applicable law or may constitute as
attorney work product.
If you are not the intended recipient, you are hereby notified that
any use, dissemination, distribution, or copying of this communication
is strictly prohibited. If you have received this communication in
error, notify us immediately by telephone and (i) destroy this message
if a facsimile or (ii) delete this message immediately if this is an
electronic communication.
Thank you.
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Res: Performance

[Wolak Sistemas - Fabiano Machado Dias]

Vou usar o mesmo exemplo que voc citou da Fiat.

V em qualquer banca de revista e voc ir encontrar dezenas de testes
dos carros da Fiat com os seus concorrentes da mesma categoria, testes
realizados por publicaes que tem nome e respeitabilidade no mercado.

Agora tente achar algo parecido com a Oracle!

No estamos falando de propaganda e sim de testes realizados comparando
dois ou mais produtos, coisa que  corriqueira no mercado atual e em
qualquer segmento, menos no caso do banco de dados Oracle.

Uma coisa interessante  que j foram feitos testes com outros
concorrentes, menos o Postgresql, por que ser? No arrisco uma
resposta!

Um grande abrao,

Fabiano Machado Dias

MARCIO CASTRO escreveu:

  
  
  Caro
Leandro:
  
a - 
"Tenho srias dvidas de que esse tipo de proibio seja
constitucional, seja aqui ou noutras partes do mundo dito civilizado."
  
 Olha s; esta atitude da Oracle  a mesma de milhes de outras
empresa pelo mundo, ok?
 Voc j viu uma propaganda da Fiat dizendo que o carro dela  melhor
do que algum carro da Wolksvagem, ou de qualquer outra marca?
 Nestas propagandas de sabo em p, volta-e-meia aparece um suposto
"teste" do produto anunciado versus o concorrente, mas sem NUNCA citar
o nome do concorrente, correto?
  
  
b - 
"E creio que esse tipo de proibio  burrice e m-f."
  
 Ento todas as outras empresas tambm so "burras" e praticam "m-f"?
 E se a Oracle " burra", ento porque se deixar publicar no TCP?
Porque est em primeiro lugar?
  
  
c - 
 E, alis, indica que trata-se dum competidor que sabe que est
perdendo, apesar das aparncias."
  
 Whats???
 Cara; a Oracle acaba de comprar a SUN por mseros 7.4 bilhes de
doletas... Isto  atitude de quem est perdendo?
 E esse tal de "estudo", por enquanto, no passa de mais uma das
lendas da internet.
  
 Sejamos srios, or favor!
  
  
  
  
  De:
Leandro DUTRA leandro.gfc.du...@gmail.com
  Para: Comunidade
PostgreSQL Brasileira pgbr-geral@listas.postgresql.org.br
  Enviadas: Domingo, 24
de Janeiro de 2010 20:04:45
  Assunto: Re:
[pgbr-geral] Performance
  
2010/1/24 Marcelo Costa marcelojsco...@gmail.com:

 2010/1/23 Leandro DUTRA leandro.gfc.du...@gmail.com

 2010/1/23 Marcelo Costa marcelojsco...@gmail.com:
  Eu j fiz um estudo desses mas por implicaes jurdicas,
inclusive
  consultei um advogado especialista na rea digital, no
posso divulgar.

 Quero ver processarem algum. Alis, s isso j me indica
m-f.

 No entendi 
  
Tenho srias dvidas de que esse tipo de proibio seja
constitucional, seja aqui ou noutras partes do mundo dito civilizado.
  
E creio que esse tipo de proibio  burrice e m-f. E, alis,
indica que trata-se dum competidor que sabe que est perdendo, apesar
das aparncias.
  
  
-- 
skype:leandro.gfc.dutra?chat   Yahoo!: ymsgr:sendIM?lgcdutra
+55 (11) 3854 7191   gTalk: xmpp:leand...@jabber.org
+55 (11) 9406 7191ICQ/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
  
  

  
  
  Veja quais so os assuntos do momento no Yahoo! +
Buscados: Top
10 - Celebridades
- Msica
- Esportes
  

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




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

Re: [pgbr-geral] Res: Res: Performance

[Wolak Sistemas - Fabiano Machado Dias]

Estava falando em relao ao PG, ou seja PG x Oracle.

Na verdade voc entendeu n? 

Outra coisa, o site  www.tpc.org e no www.tcp.org

Abrao,
Fabiano Machado Dias

MARCIO CASTRO escreveu:

  
  
  "Agora tente achar algo parecido com a Oracle!"
  
  www.tcp.org
  
  
  
  
  
  De: Wolak
Sistemas - Fabiano Machado Dias fabi...@wolaksistemas.com.br
  Para: Comunidade
PostgreSQL Brasileira pgbr-geral@listas.postgresql.org.br
  Enviadas: Domingo, 24
de Janeiro de 2010 21:21:57
  Assunto: Re:
[pgbr-geral] Res: Performance
  
  
Vou usar o mesmo exemplo que voc citou da Fiat.
  
V em qualquer banca de revista e voc ir encontrar dezenas de testes
dos carros da Fiat com os seus concorrentes da mesma categoria, testes
realizados por publicaes que tem nome e respeitabilidade no mercado.
  
Agora tente achar algo parecido com a Oracle!
  
No estamos falando de propaganda e sim de testes realizados comparando
dois ou mais produtos, coisa que  corriqueira no mercado atual e em
qualquer segmento, menos no caso do banco de dados Oracle.
  
Uma coisa interessante  que j foram feitos testes com outros
concorrentes, menos o Postgresql, por que ser? No arrisco uma
resposta!
  
Um grande abrao,
  
Fabiano Machado Dias
  
MARCIO CASTRO escreveu:
  

Caro
Leandro:

a - 
"Tenho srias dvidas de que esse tipo de proibio seja
constitucional, seja aqui ou noutras partes do mundo dito civilizado."

 Olha s; esta atitude da Oracle  a mesma de milhes de outras
empresa pelo mundo, ok?
 Voc j viu uma propaganda da Fiat dizendo que o carro dela  melhor
do que algum carro da Wolksvagem, ou de qualquer outra marca?
 Nestas propagandas de sabo em p, volta-e-meia aparece um suposto
"teste" do produto anunciado versus o concorrente, mas sem NUNCA citar
o nome do concorrente, correto?


b - 
"E creio que esse tipo de proibio  burrice e m-f."

 Ento todas as outras empresas tambm so "burras" e praticam "m-f"?
 E se a Oracle " burra", ento porque se deixar publicar no TCP?
Porque est em primeiro lugar?


c - 
 E, alis, indica que trata-se dum competidor que sabe que est
perdendo, apesar das aparncias."

 Whats???
 Cara; a Oracle acaba de comprar a SUN por mseros 7.4 bilhes de
doletas... Isto  atitude de quem est perdendo?
 E esse tal de "estudo", por enquanto, no passa de mais uma das
lendas da internet.

 Sejamos srios, or favor!




De:
Leandro DUTRA leandro.gfc.du...@gmail.com
Para: Comunidade
PostgreSQL Brasileira pgbr-geral@listas.postgresql.org.br
Enviadas: Domingo,
24
de Janeiro de 2010 20:04:45
Assunto: Re:
[pgbr-geral] Performance

2010/1/24 Marcelo Costa marcelojsco...@gmail.com:

 2010/1/23 Leandro DUTRA leandro.gfc.du...@gmail.com

 2010/1/23 Marcelo Costa marcelojsco...@gmail.com:
  Eu j fiz um estudo desses mas por implicaes jurdicas,
inclusive
  consultei um advogado especialista na rea digital, no
posso divulgar.

 Quero ver processarem algum. Alis, s isso j me indica
m-f.

 No entendi 

Tenho srias dvidas de que esse tipo de proibio seja
constitucional, seja aqui ou noutras partes do mundo dito civilizado.

E creio que esse tipo de proibio  burrice e m-f. E, alis,
indica que trata-se dum competidor que sabe que est perdendo, apesar
das aparncias.


-- 
skype:leandro.gfc.dutra?chat   Yahoo!: ymsgr:sendIM?lgcdutra
+55 (11) 3854 7191   gTalk: xmpp:leand...@jabber.org
+55 (11) 9406 7191ICQ/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




Veja quais so os assuntos do momento no Yahoo! +
Buscados: Top
10 - Celebridades
- Msica
- Esportes

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

  
  
  Veja quais so os assuntos do momento no Yahoo! +
Buscados: Top
10 - Celebridades
- Msica
- Esportes
  

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




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

Re: [pgbr-geral] Res: Digest pgbr-geral, volume 35, assunto 94

[Wolak Sistemas - Fabiano Machado Dias]

Se o seu sistema j estava escrito em Oracle e voc apenas migrou para
o Postgresql como voc queria que tivesse o mesmo desempenho?

Voc teria que rever a sua escrita porque com certeza o cdigo que voc
escreveu foi otimizado para rodar no Oracle, para fazer a migrao voc
deveria ter o mesmo cuidado e analisar o cdigo que foi portado para o
Postgresql.

Tambm j ouvi de fonte confivel que em testes realizados comparando
os dois bandos o PG chegou a ser at 50% mais rpido que o Oracle, mas
 claro que esse teste no foi publicado e nem ser.

Abrao,
Fabiano Machado Dias







Euler Taveira de Oliveira escreveu:

  MARCIO CASTRO escreveu:
  
  
  Trabalho com o Postgres e com o Oracle, e relato que a diferena entre
os mesmos  abismal.

  
  Discordo. No *generalize* as coisas; j vi vrias instalaes PostgreSQL com
performance superior a anterior (aka Or*cle).

  
  
  Tentamos inclusive importar um sistema com milhares de funes e
procedimentos em PL/SQL (Oracle 10g) para o PL/pgSQL, mas os primeiros
testes nos revelaram que a performance cairia demais, tornando o projeto
invivel.

  
  Voc _no_ mostrou a funo em PL/SQL e nem a equivalente em PL/pgSQL.

  
  
  Na poca, cheguei at a buscar auxlio na lista, escrevendo dois
pequenos exemplos para isto. Alguns at me auxiliaram, propondo que as
rotinas fossem reescritas em C, mas mesmo assim o Oracle foi mais rpido.

  
  Oracle mais rpido? Eu *no* vi esses resultados em [1][2]. Voc s mostrou os
resultados do Oracle e _no_ do PostgreSQL com a funo em C.

A concluso daquela discusso foi que voc estava "batendo em espantalho"; use
os mtodos adequados para obter melhor desempenho.

  
  
PS: http://www.tpc.org/tpcc/results/tpcc_perf_results.asp
Continuo torcendo para que um dia vejamos o Post nesta lista!


  
  Para isso precisamos pagar um bom $$$ para associarmos e termos direito de
fazer tais testes. E,  claro, termos hardwares disponveis para realizar os
testes. (Sem uma grande empresa com acesso aos vendedores de hardware, fica
difcil realizarmos tal tarefa).


[1]
http://listas.postgresql.org.br/pipermail/pgbr-geral/2009-September/017497.html
[2]
http://listas.postgresql.org.br/pipermail/pgbr-geral/2009-September/017498.html


  




___
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: Res: Res: Res: Res: Uso de Campos Padrões

[Wolak Sistemas - Fabiano Machado Dias]

Concordo!!!

E também não precisa ficar bravo porque outras pessoas tem opiniões
diferentes de você. 

Afinal esse é o grande trunfo da lista e o que faz o conhecimento
crescer e se espalhar!

Abração,
Fabiano Machado Dias

MARCIO CASTRO escreveu:

  
  
  Sinto; mas o intuito da lista é partilhar conhecimentos. Se não
for do seu intuito, não responda.
  
  
  
  
  
  
  De:
Leandro DUTRA leandro.gfc.du...@gmail.com
  Para: Comunidade
PostgreSQL Brasileira pgbr-geral@listas.postgresql.org.br
  Enviadas: Terça-feira,
5 de Janeiro de 2010 14:59:59
  Assunto: Re:
[pgbr-geral] Res: Res: Res: Res: Res: Res: Uso de Campos Padrões
  
2010/1/5 MARCIO CASTRO marciomouracas...@yahoo.com.br:
 Colega; então explique!
  
Talvez eu o faça, mas como você imaginou coisas que nunca escrevi,
fica difícil saber o que explicar.
  
Especificamente, ainda se usa COBOL, mainframes tinham, e ainda têm,
gibibytes de memória, usam discos rígidos, rodam grandes programas… e
não é só COBOL que lida bem com bases de dados.  Mas o que você não
entendeu, não sei dizer.
  
  
 A lista serve para isto, não é?
  
Não para dar aulas de graça…
  
  
 Mas se você não quer explicar, então é só NÃO RESPONDER.
  
Melhor parar por aqui…
  
  
-- 
skype:leandro.gfc.dutra?chat      Yahoo!: ymsgr:sendIM?lgcdutra
+55 (11) 3854 7191              gTalk: xmpp:leand...@jabber.org
+55 (11) 9406 7191        ICQ/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
  
  

  
  
  Veja quais são os assuntos do momento no Yahoo! +
Buscados: Top
10 - Celebridades
- Música
- Esportes
  

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




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

Re: [pgbr-geral] Uso de Campos Padrões

[Wolak Sistemas - Fabiano Machado Dias]

Leandro DUTRA escreveu:

  2009/12/29  fabi...@wolaksistemas.com.br:
  
  

  2009/12/29  fabi...@wolaksistemas.com.br:
  
  

  2009/12/29  lis...@softpira.com:
  
  
) WITH ( OIDS=TRUE);

  

  
  Porque não tem utilidade, engorda a base e ainda possibilita erros de
rpogramação.

  

Não é o nosso caso, usamos os OIDS para algumas coisas internas como
posicionamento de cursores, melhor que criar uma estrutura só para
controlar isso.

  
  
Pelo contrário… OIDs podem alterarem-se com restauração de cópias de
segurança, podem ciclar… melhor criar algo que esteja no modelo, se
for uma necessidade real.  OIDs são resquício da tentativa
(fracassada) de se fazer um SGBD SQL-OO.

  

--- Sei disso. Mas não é o tipo de uso que você esta imaginando.

  
  
  
sempre li que é para evitar chaves naturais como pk.

  
  
Por quê?

Pelo contrário, uma chave artificial não evita duplicidade, engorda a
base e dificulta o entendimento do modelo.

  

--- Não evita duplicidade? Me de um exemplo ou um case por favor,
porque então a documentação está errada e tudo o que li tb.
Uma chave natural por exemplo CPF, nada te garante que no futuro não
irá mudar o padrão e ali o teu modelo foi pro saco.

  
  
  
Usar uma chave artificial te livra de um monte de dor de cabeça

  
  
Por exemplo?

Pelo contrário, usar chaves artificiais, a médio prazo, gera muita dor
de cabeça porque engorda a base (geralmente) e obscurece o modelo
(sempre).  Muitas vezes, nem se definem boas chaves naturais porque se
usou o quebra-galho da artificial.


  

--- Exemplos pf, engorda a base? Pelo que entendo facilita até a
maneira que o banco trabalha. Obscurece o modelo? Por favor seja mais
específico.


  
  
Bah daí concordo contigo! O nome poderia ser outro, mas essa é uma
daquelas coisas que acabam ficando pra trás, no nosso caso é uma UK
tanto no nome como na função hehe!

  
  
O tipo da alteração que pode valer a pena, embora possa ser meio traumática.


  

--- Como hj estamos envolvidos com outros módulos do sistema já não
vale a pena ficar mudando apenas para ficar "bonito e no padrão". 

  
  
Bom daí já discordo um pouco. Pra mim base e modelo que precisam ser
alterados no meio do caminho é igual a sistema mal feito e mal
projetado.

  
  
A curto prazo, sim.  A longo, não.


  


  
Até agora estão se mostrando excelentes, tomara que continuem assim.

As vezes a teoria é uma coisa, mas na prática é outra!

  
  
Não vão continuar, são típicas decisões sem fundamento teórico nem, a
longo prazo, prático.  Regras criadas por desenvolvedores que nem
entendiam dados, nem tiveram de dar manutenção em sistemas evoluídos
ao longo do tempo.  Algumas até generalizações incorretas de situações
específicas.


  

--- Essa afirmação é bem contundente, mas como esse sistema já está a 3
anos rodando no primeiro cliente (indústria com faturamento médio de 5
milhões mensais) acredito que já estamos no meio do caminho e se o
modelo se mostrou eficiente até agora, duvido que vou ter problemas
daqui pra frente, de qualquer forma vou guardar esse email e daqui a
alguns anos tiramos a prova.

Citando um trecho de uma palestra do Telles:

"- Uma pessoa sem bom senso não se preocupa com melhores práticas
- Uma pessoa com bom senso e pouca experiência procura aprender e
utilizar as melhores práticas
- Uma pessoa com bom senso e muita experiência sabe quando não utilizar
as melhores práticas"

Abração,
Fabiano Machado Dias


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

Re: [pgbr-geral] Uso de Campos Padrões

[Wolak Sistemas - Fabiano Machado Dias]

Nesse exemplo você confundiu PK com UK. Mas vamos deixar pra lá!

Leandro DUTRA escreveu:

  2009/12/30 Andre Fernandes fernandes.an...@gmail.com:
  
  
Desculpa-me entrar nesta discussão, contudo neste exemplo mencionado há um
possível erro de modelagem, o problema não é a chave artificial explicitamente.

  
  
Como eu disse, é um exemplo simplérrimo, somente para demonstrar o
problema, a saber que chave artificial não garante unicidade.


  
  
Chaves artificiais não são um mal por si só

  
  
Na forma como implementadas hoje, são.  Originalmente, eram uma idéia
interessante, mas creio que não foram implementadas em nenhum sistema.

Infelizmente, são um mal necessário em algumas situações.  Mas somente
complementando as naturais, nunca substituindo.


  
  
Concordo que chaves artificiais podem ser problema quando o modelo está errado

  
  
Não apenas, podem ser problemas físicos também.


  
  
nem sempre chaves naturais são adequadas ou mesmo possuem bom desempenho

  
  
Sempre são adequadas e sempre possuem bom desempenho — a não ser em
situações bem específicas, como já descritas.


  
  
(imagine uma chave composta onde todos os campos são strings, pode ser muito
ruim para um bom desempenho de consultas).

  
  
Mito.


  
  
Além do mais, um id interno para o usuário, para a empresa, etc., pode ser
facilmente entendido, não é um monstro que complica tudo.

  
  
Mas obscurece quais as chaves verdadeiras.  Geralmente, dificulta o
entendimento.


  
  
(lembre-se que nem as regras de normalização sempre devem ser seguidas, há
momentos em que precisamos ferir uma delas para que o desempenho não seja
ínfimo).

  
  
Mas isso por limitações do SQL.


  




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

Re: [pgbr-geral] Desempenho no Linux

[Wolak Sistemas - Fabiano Machado Dias]

Pessoal, não vamos esquecer de outros fatores que fazem o Linux ter um
desempenho muito melhor.

- Sistemas de aquivos (Qual a opção que existe no Windows além de NTFS?)
- Parâmetros do Kernel (Só se você por um expert no registro do
Windows, quais os parâmetros que você pode mudar?)
- Instalação via código fonte (Sei que tb dá pra compilar no Windows,
mas duvido alguém que faça sem dor de cabeça e tb duvido do desempenho)
- Melhor uso de hardware (Isso é senso comum, o Linux faz uso do
hardware de maneira muito mais otimizada que o Windows)
- Segurança (Bom como diz o Telles "Existem 2 tipos de Windows, aquele
que tem vírus e aquele que você acha que não tem vírus")

Para convencer o seu cliente você poderia fazer uma instalação em um
servidor da sua própria em empresa e comparar o desempenho, duvido que
ele não irá se convencer.

Abraço,
Fabiano



Euler Taveira de Oliveira escreveu:

  Pablo Sánchez escreveu:
  
  
"PostgreSQL performance is very close on both platforms (within 6/100
of a second for 1000 Operations) – It’s faster on Windows and faster
still on Windows with PHP 5.3"


  
  Ugh?! Quem disse que 'SELECT * FROM tabela' mede performance de um SGBD? O
autor deve estar brincando, né? Temos benchmarks padronizados (aka TPC) para
isso; eles implementam modelos que simulam um ambiente real de acordo com a
arquitetura (OLTP, OLAP ou Web) do seu sistema.

  
  
Não conheço nenhuma diferença... Com exceção do fato de que há
tunnings que podem ser feitos com os semáforos do kernel em
Linux/FreeBSD que não se conseguem no Windows.


  
  Como eu disse esses conceito *não* existe (é emulado) no Windows.


  




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

Re: [pgbr-geral] Desempenho no Linux

[Wolak Sistemas - Fabiano Machado Dias]

Pablo Sánchez escreveu:

  2009/11/26 Wolak Sistemas - Fabiano Machado Dias fabi...@wolaksistemas.com.br:
  
  
Pessoal, não vamos esquecer de outros fatores que fazem o Linux ter um
desempenho muito melhor.

- Sistemas de aquivos (Qual a opção que existe no Windows além de NTFS?)

  
  
Mas será que precisa de algum outro além desse para ele? (obs, existe
fat32, vc pode compilar partições maiores que 4GB de fat32 utilizando
uma ferramenta chamada fat32format.exe - não é padrão do windows, mas
é gratuita

FAT 32? Bah, tá loco, isso nem deveria ser considerado um sistema de
arquivos. E acho que é importante você poder contar com mais opção de
file system, já tive situações onde coloquei os dados em XFS, indíces
em EXT2, e logs em ReiserFS. 
Era um caso específico e a performance ficou melhor, mas me diz qual a
opção que teria em Windows? Nenhuma!

  
  
- Parâmetros do Kernel (Só se você por um expert no registro do Windows,
quais os parâmetros que você pode mudar?)

  
  
Eu faço uma limpeza de alguns parâmetros que já conheço serem
desnecessários e que só deixam o OS mais lento, mas isso desde o winnt
4... então meio que realmente, não sei de muita gente que faça isso na
mão hoje em dia.

  

Blz, acho que pode até ser válido, agora muda os semáforos do SO,
ajusta a memória compartilhada, muda o tamanho da pilha, e outra sem
reiniciar o sistema, afinal tu vai derrubar a empresa só pra mudar
alguns parâmetros?


  
  
- Instalação via código fonte (Sei que tb dá pra compilar no Windows, mas
duvido alguém que faça sem dor de cabeça e tb duvido do desempenho)

  
  
Sem dor de cabeça é complicado mesmo, mas vai falar com o Guilherme
Blanco que é o cara responsável pelo windows.php.net. ;-)

  
  
- Melhor uso de hardware (Isso é senso comum, o Linux faz uso do hardware de
maneira muito mais otimizada que o Windows)

  
  
Senso comum não é comprovação. Os drivers de placas 3D para windows
são no geral muito melhores que o do Linux, até mesmo porque tem
pouquíssima placa com driver oficial para o Linux...

É senso comum que o céu é azul, mas é cientificamente comprovado que
não existem as cores, apenas o espectro de luz. A cor é mera
interpretação do cérebro, e o que é azul para mim (ou seja, exatamente
como meu cérebro me apresenta) poderia ser o verde para vc.

Senso comum é subjetivo, não serve como parâmetro... é a interpretação
ordinária de cada um sobre o que todo mundo fala e quase ninguém para
para comprovar.

Tem pesquisas por aí que suportam a argumentação, e acho que nosso
amigo precisa delas, e não de "senso comum".

  

Bom quis dizer senso comum porque a maioria das pessoas que trabalham e
conhecem o Linux sabem disso, mas só para elucidar o porque posso citar
algumas coisas:

- Linux e o Kernel foram feitos para rodar em hardware barato, desde o
início a preocupação com performance foi uma constante.
- O uso de memória e processador e a maneira de controlar os processos
são melhores que qualquer sistema Windows, até pouco tempo atrás o
Windows tinha problema em gerenciar 4 gb de memória.
- Drivers de Placa 3d? Bom estamos ou pelo menos eu estava falando em
servidores, onde os drivers realmente importantes são os das
controladoras de disco, rede etc... 
Lembro de uma situação onde estava instalando um Debian em um servidor
Dell, durante a instalação veio uma mensagem dizendo que eu precisaria
de um pacote para a atualização do firmware da placa de rede, pois a
mesma tinha problemas no driver nativo.
Entrei no repositório de pacotes, baixei, pluguei um pendrive e a
instalação continuou e este server está rodando até agora.

Talvez a expressão senso comum não foi a mais correta, mas sei lá até
leigos hoje em dia sabem que Linux é mais rápido que Windows, talvez
porque é o sistema mais usado em servidores no mundo inteiro, sei lá!

  
  
- Segurança (Bom como diz o Telles "Existem 2 tipos de Windows, aquele que
tem vírus e aquele que você acha que não tem vírus")

Para convencer o seu cliente você poderia fazer uma instalação em um
servidor da sua própria em empresa e comparar o desempenho, duvido que ele
não irá se convencer.

Abraço,
Fabiano



Euler Taveira de Oliveira escreveu:

Pablo Sánchez escreveu:


"PostgreSQL performance is very close on both platforms (within 6/100
of a second for 1000 Operations) – It’s faster on Windows and faster
still on Windows with PHP 5.3"



Ugh?! Quem disse que 'SELECT * FROM tabela' mede performance de um SGBD? O
autor deve estar brincando, né? Temos benchmarks padronizados (aka TPC) para
isso; eles implementam modelos que simulam um ambiente real de acordo com a
arquitetura (OLTP, OLAP ou Web) do seu sistema.



Não conheço nenhuma diferença... Com exceção do fato de que há
tunnings que podem ser feitos com os semáforos do kernel em
Linux/FreeBSD que não se conseguem no Windows.



Como eu disse esses conceito *não* existe (é emulado) no Windows.