Re: [pgbr-geral] formatação_Moeda.
Altere no postgresql.conf = LC_NUMERIC= 'pt_BR' LC_MONETARY = 'pt_BR' TENTE ALGO MAIS OU MENOS ASSIM -SUBSTITUIR TODOS OS SEPARADORES DE GRUPO (G) POR ESPAÇO. -SUBSTITUIR TODOS OS ESPAÇOS POR PONTO. REPLACE(TRIM(TO_CHAR(REPLACE(CAMPO, ''99G999D99'' ,'G', ' '))), ' ', '.'); PS - O caminho é +- este. ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
[pgbr-geral] FUNCTION EM JAVA NO POSTGRESQL
Pessoal, alguém desenvolve funções em java no postgresql. Possuem exemplos, apostilas...etc ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Tempo excecivo ao restaurar banco
Benedito A. Cruz escreveu: Não é demais lembrar que deve-se parar o postmaster pra fazer isso... Eu faço dos dois jeitos, via pg_dump e via tar. []s Bene Leandro Damascena escreveu: Sergio Medeiros Santi escreveu: Não tinha pensado não, até porque não sabia que era recomendável. Como se faz isto? Procuro por backup físico? Não tinha houvido falar nisto no PG. O backup físico nada mais é que vc pegar a pasta onde tem os dados do banco (sua configuração pgdata define isso) e copiar direto pra sua fita/dvd/hd/nfs/smb ou outro dispositivo/sistema de armazenamento de dados. Você pode zipar também que ajudaria a economizar espaço, se bem que no windows fazer um zip de 30GB não deve ser nada rápido :P Contudo não acho uma base de 30G tão grande assim e principalmente acho estranho que das aproximadamente 12 horas que o processo de restauração complata consuma 8 horas sejam consumidas pela contraint que citei. Eu esperava que alguém me abrisse os olhos para alguma babaquice minha. Abraços, Sergio Medeiros Santi Leandro ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral Não daria para fazer o backup em outra máquina usando o rsync acredito que seria mais rápido. Como ja teria um postgresql identico na outra máquina rondado era so levantar o BD. ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Tempo excecivo ao restaurar banco
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Sergio Medeiros Santi escreveu: (...) No exemplo abaixo eu já verifiquei e existe índice pelos dois campos envolvidos um deles é a própria primary key. ALTER TABLE ONLY NotaItem ADD Constraint NotaItem_CodigoProduto_Produto_FK FOREGN KEY (CodigoProdutoItem REFERENCES Produto (CodigoInternoProduto) MATH FULL ON UPDATE RESTRICT ON DELETE RESTRICT; Posso até estar enganado, mas tem que haver uma explicação para este tempo absurdo ou alguma mancada muito grande. Só por curiosidade. Enquanto você está restaurando o backup, a(s) aplicação(ões) que acessa(m) essas tabelas encontra(m)-se acessível(eis) também? Você já tentou dar uma olhada na pg_locks para ver se não está ocorrendo uma concorrência ai na história? Parece bobo, mas as vezes algumas resposta podem estar onde nós menos esperamos. []s Guedes -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iD8DBQFHYR23fNj5A+QkLMoRAlbTAJ48MQDFYxvuVKrur1ou+oD+1QvIEwCeNgce CEu9jFSF38gENXyBiTTRy2M= =MpcJ -END PGP SIGNATURE- ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Tempo excecivo ao restaurar banco - M ais alguém se habilita?
Pessoal:
Ontem as 12 horas eu larguei a restaurao novamente. As novas
informaes so as seguintes:
Tempo total de restaurao olhando pelos logs registrados: 14:03 (14
horas!)
Tempo total da aplicao da constraint listada abaixo: 12:13 (12
horas!!!)
Olha eu agradeo as sugestes de fazer backup "fsico", das informaes
de tempo de outros usurios, mas eu continuo achando que tem algo
errado no meu caso. Uma nica constraint consumindo 12 horas de um
total de 14 horas necessrios! Acho demais. Outro fato interessante
que, dentro do que acompanhei da aplicao da constraint o consumo de
processador baixssimo (menos de 10% em um Xeon 2.13), bem como
apresenta baixo consumo de memria e baixa atividade de disco. Parece
simplesmente que esta etapa da restaurao est fazendo corpo mole,
operao tartaruga.
Tambm j citei o tamanho da base (30G ao fazer o backup e 21G aps a
restaurao) e o nmero de registros das duas tabelas envolvidas
(NotaItem com 20.000.000 de registros e Produto com 40.000 registros).
Pelo nvel tcnico das discusses que acompanho nesta lista eu esperava
algum questionamento, ou sugesto mais relacionado ao problemas, ou ao
menos uma afirmao de que os tempos que citei so normais (o que no
acredito).
Algum sabe me dizer o que justifica que uma nica contraint consumir
tanto tempo? A mesma tabela aplica outras constraints em muito menos
tempo (NotaItem com 20.000.000 de registros e NotaFiscal com 1.400.000
registros) por exemplo, consome 4 minutos. Existe alguma forma de fazer
um explain analyse de uma constraint?
Pelo nvel das discusses que tenho acompanhado estou estranhando a
falta de comentrios "profundos" sobre este caso que tenho estudado a
uns 6 meses. Este caso me bastante instigante e no consigo apenas me
conformar com a situao. De tempos em tempo eu a retomo. Ou resolvo
isto ou acho uma explicao plausvel sobre o caso. No pretendo
concluir que este fato deva-se a "Vontade de Deus" e que devo me
resignar.
No vou jogar isto para baixo do tapete!
Sergio Medeiros Santi
Sergio Medeiros Santi escreveu:
Gente:
Essa discusso sobre o backup "fsico" foi bem elucidativo, mas
voltando a origem da thread ... Ningum, alm de mim, acha estranho que
todo o processo de restore consuma 12 horas, sendo que uma nica
contraint consuma 3/4 deste tempo e que o resto criao da estrutura,
carga dos dados, criao de indices, criao de todas as demais
constraints consuma apenas 1/4 do tempo?
No exemplo abaixo eu j verifiquei e existe ndice pelos dois campos
envolvidos um deles a prpria primary key.
ALTER TABLE ONLY
"NotaItem" ADD Constraint
"NotaItem_CodigoProduto_Produto_FK" FOREGN KEY
("CodigoProdutoItem" REFERENCES
"Produto" ("CodigoInternoProduto") MATH FULL ON UPDATE RESTRICT
ON DELETE RESTRICT;
Posso at estar enganado, mas tem que haver uma
explicao para este tempo absurdo ou alguma mancada muito grande.
Abraos,
Sergio Medeiros Santi
__ Informao do NOD32 IMON 2719 (20071212) __
Esta mensagem foi verificada pelo NOD32 sistema antivrus
http://www.eset.com.br
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
__ Informao do NOD32 IMON 2719 (20071212) __
Esta mensagem foi verificada pelo NOD32 sistema antivrus
http://www.eset.com.br
___
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 EM JAVA NO POSTGRESQL
O google é nosso pai e nada nos faltará http://wiki.tada.se/display/pljava/User+Guide http://www.guj.com.br/posts/downloadAttach/374.java Leandro Julio Cesar Merenda Catardo escreveu: Pessoal, alguém desenvolve funções em java no postgresql. Possuem exemplos, apostilas...etc ** ___ 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] RE: Tempo excecivo ao restaurar b anco - Mais alguém se habilita?
Olá, Só uma pergunta. Se remover esta constraint no banco em operação, passar um vacuum, quanto tempo demora para que seja criada novamente ? Pode ser que na restauração ele não consiga usar os indices por algum motivo, talves eles ainda não estejam atualizados com estatisticas ou ainda não foram criados. Claudio Oliveira http://www.msisolucoes.com.br Date: Thu, 13 Dec 2007 09:07:31 -0300From: [EMAIL PROTECTED]: [EMAIL PROTECTED]: Re: [pgbr-geral] Tempo excecivo ao restaurar banco - Mais alguém se habilita? Pessoal:Ontem as 12 horas eu larguei a restauração novamente. As novas informações são as seguintes:Tempo total de restauração olhando pelos logs registrados: 14:03 (14 horas!)Tempo total da aplicação da constraint listada abaixo: 12:13 (12 horas!!!)Olha eu agradeço as sugestões de fazer backup físico, das informações de tempo de outros usuários, mas eu continuo achando que tem algo errado no meu caso. Uma única constraint consumindo 12 horas de um total de 14 horas necessários! Acho demais. Outro fato interessante é que, dentro do que acompanhei da aplicação da constraint o consumo de processador é baixíssimo (menos de 10% em um Xeon 2.13), bem como apresenta baixo consumo de memória e baixa atividade de disco. Parece simplesmente que esta etapa da restauração está fazendo corpo mole, operação tartaruga.Também já citei o tamanho da base (30G ao fazer o backup e 21G após a restauração) e o número de registros das duas tabelas envolvidas (NotaItem com 20.000.000 de registros e Produto com 40.000 registros). Pelo nível técnico das discussões que acompanho nesta lista eu esperava algum questionamento, ou sugestão mais relacionado ao problemas, ou ao menos uma afirmação de que os tempos que citei são normais (o que não acredito).Alguém sabe me dizer o que justifica que uma única contraint consumir tanto tempo? A mesma tabela aplica outras constraints em muito menos tempo (NotaItem com 20.000.000 de registros e NotaFiscal com 1.400.000 registros) por exemplo, consome 4 minutos. Existe alguma forma de fazer um explain analyse de uma constraint?Pelo nível das discussões que tenho acompanhado estou estranhando a falta de comentários profundos sobre este caso que tenho estudado a uns 6 meses. Este caso me é bastante instigante e não consigo apenas me conformar com a situação. De tempos em tempo eu a retomo. Ou resolvo isto ou acho uma explicação plausível sobre o caso. Não pretendo concluir que este fato deva-se a Vontade de Deus e que devo me resignar. Não vou jogar isto para baixo do tapete!Sergio Medeiros Santi Sergio Medeiros Santi escreveu: Gente:Essa discussão sobre o backup físico foi bem elucidativo, mas voltando a origem da thread ... Ninguém, além de mim, acha estranho que todo o processo de restore consuma 12 horas, sendo que uma única contraint consuma 3/4 deste tempo e que o resto criação da estrutura, carga dos dados, criação de indices, criação de todas as demais constraints consuma apenas 1/4 do tempo?No exemplo abaixo eu já verifiquei e existe índice pelos dois campos envolvidos um deles é a própria primary key.ALTER TABLE ONLY NotaItem ADD Constraint NotaItem_CodigoProduto_Produto_FK FOREGN KEY (CodigoProdutoItem REFERENCES Produto (CodigoInternoProduto) MATH FULL ON UPDATE RESTRICT ON DELETE RESTRICT;Posso até estar enganado, mas tem que haver uma explicação para este tempo absurdo ou alguma mancada muito grande.Abraços,Sergio Medeiros Santi __ Informação do NOD32 IMON 2719 (20071212) __Esta mensagem foi verificada pelo NOD32 sistema antivírushttp://www.eset.com.br ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral __ Informação do NOD32 IMON 2719 (20071212) __ Esta mensagem foi verificada pelo NOD32 sistema antivírus http://www.eset.com.br _ Confira vídeos com notícias do NY Times, gols direto do Lance, videocassetadas e muito mais no MSN Video! http://video.msn.com/?mkt=pt-br___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Tempo excecivo ao restaurar banco - M ais alguém se habilita?
Sergio Medeiros Santi escreveu:
ALTER TABLE ONLY
"NotaItem" ADD Constraint
"NotaItem_CodigoProduto_Produto_FK" FOREGN KEY
("CodigoProdutoItem" REFERENCES
"Produto" ("CodigoInternoProduto") MATH FULL ON UPDATE RESTRICT
ON DELETE RESTRICT;
J tentou alterar de RESTRICT para NO ACTION?
A coluna notaitem.codigoprodutoitem tem INDEX?
Se voc simplesmente dropar a fk e cri-la novamente (pelo pgAdmin
mesmo) fica lento?
Att
Evandro
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Tempo excecivo ao restaurar banco
2007/12/13, Mateus [EMAIL PROTECTED]: Benedito A. Cruz escreveu: Não é demais lembrar que deve-se parar o postmaster pra fazer isso... Eu faço dos dois jeitos, via pg_dump e via tar. Não daria para fazer o backup em outra máquina usando o rsync acredito que seria mais rápido. Como ja teria um postgresql identico na outra máquina rondado era so levantar o BD. E a integridade dos arquivos, que são constantemente alterados? Por isso que existe toda a infra do MVCC possibilitando cópias de segurança a quente. -- +55 (11) 5685 2219 xmpp:[EMAIL PROTECTED] +55 (11) 9406 7191 Yahoo!: ymsgr:sendIM?lgcdutra +55 (11) 3040 7300 ICQ/AIM: aim:GoIM?screenname=61287803 MSN: msnim:[EMAIL PROTECTED] ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Tempo excecivo ao restaurar banco - Mais a lguém se habilita?
2007/12/13, Sergio Medeiros Santi [EMAIL PROTECTED]: Pelo nível das discussões que tenho acompanhado estou estranhando a falta de comentários profundos sobre este caso que tenho estudado a uns 6 meses. Pode ser simplesmente falta de tempo dos gurus… dica: para casos como esse, muitos deles são freelas. -- +55 (11) 5685 2219 xmpp:[EMAIL PROTECTED] +55 (11) 9406 7191 Yahoo!: ymsgr:sendIM?lgcdutra +55 (11) 3040 7300 ICQ/AIM: aim:GoIM?screenname=61287803 MSN: msnim:[EMAIL PROTECTED] ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
[pgbr-geral] Configuração de servidor para com pra
Olá a todos, Estou precisando comprar um servidor para rodar: - SO: to pensando no Debian. - Apache com PHP - DNS - PostgreSQL: bases pequenas de até 1 giga ( várias) - Email - Mysql para bases pequenas , email etc A carga do servidor, inicialmente seria de uns 10 domínios com aplicações em html/php. Acho que dificilmente passaria de 100 domínios. As bases do Postgresql, a maioria seriam bases pequenas de até 50 megas, algumas ( no máximo 5 ) com até 500 megas. Sobre usuários simultâneos, acredito que deveria atender até 30 sei lá. Bom, sei que rodar isso tudo em uma máquina seria complicado em um ambiente com muitos usuários simultaneos, bases de dados maiores, mas inicialmente, serão poucos usuários simultâneos. Poderiam me sugerior a configuração recomendada? ( Levando em consideração custo benefício ) Mais uma pergunta, é melhor eu ter dois servidores replicados (humildes) ou ter apenas um robusto ? Bom, gostaria da opinião geral de vocês sobre qual ambiente ideal para atender a estes requisitos, levando em consideraão mais uma vez, custo benefício, hehehe. ps - Desculpem o longo texto. []s Fernando de Oliveira ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Tempo excecivo ao restaurar banco - M ais alguém se habilita?
Olá Sergio, Você não pode mudar só um pouco a estratégia do seu backup/restore? Por exemplo, primeiro você faz uma restauração somente do esquema da tua base, tabelas, constraints e afins. E depois, como segunda etapa, restaurar somente os dados? Pode ser uma possibilidade. Alguns outros detalhes, você não está com nenhuma trigger sendo disparada nessa tabela ou em alguma outra? Não tem nenhum lock travando esta tabela, ou uma referência circular? Qualquer coisa, você pode postar o problema para o pessoal da lista oficial do PG, talvez a performance ou a admin possam lhe ajudar. Até mais. Fernando Simon Sergio Medeiros Santi wrote: Pessoal: Ontem as 12 horas eu larguei a restauração novamente. As novas informações são as seguintes: Tempo total de restauração olhando pelos logs registrados: 14:03 (14 horas!) Tempo total da aplicação da constraint listada abaixo: 12:13 (12 horas!!!) Olha eu agradeço as sugestões de fazer backup físico, das informações de tempo de outros usuários, mas eu continuo achando que tem algo errado no meu caso. Uma única constraint consumindo 12 horas de um total de 14 horas necessários! Acho demais. Outro fato interessante é que, dentro do que acompanhei da aplicação da constraint o consumo de processador é baixíssimo (menos de 10% em um Xeon 2.13), bem como apresenta baixo consumo de memória e baixa atividade de disco. Parece simplesmente que esta etapa da restauração está fazendo corpo mole, operação tartaruga. Também já citei o tamanho da base (30G ao fazer o backup e 21G após a restauração) e o número de registros das duas tabelas envolvidas (NotaItem com 20.000.000 de registros e Produto com 40.000 registros). Pelo nível técnico das discussões que acompanho nesta lista eu esperava algum questionamento, ou sugestão mais relacionado ao problemas, ou ao menos uma afirmação de que os tempos que citei são normais (o que não acredito). Alguém sabe me dizer o que justifica que uma única contraint consumir tanto tempo? A mesma tabela aplica outras constraints em muito menos tempo (NotaItem com 20.000.000 de registros e NotaFiscal com 1.400.000 registros) por exemplo, consome 4 minutos. Existe alguma forma de fazer um explain analyse de uma constraint? Pelo nível das discussões que tenho acompanhado estou estranhando a falta de comentários profundos sobre este caso que tenho estudado a uns 6 meses. Este caso me é bastante instigante e não consigo apenas me conformar com a situação. De tempos em tempo eu a retomo. Ou resolvo isto ou acho uma explicação plausível sobre o caso. Não pretendo concluir que este fato deva-se a Vontade de Deus e que devo me resignar. Não vou jogar isto para baixo do tapete! Sergio Medeiros Santi Sergio Medeiros Santi escreveu: Gente: Essa discussão sobre o backup físico foi bem elucidativo, mas voltando a origem da thread ... Ninguém, além de mim, acha estranho que todo o processo de restore consuma 12 horas, sendo que uma única contraint consuma 3/4 deste tempo e que o resto criação da estrutura, carga dos dados, criação de indices, criação de todas as demais constraints consuma apenas 1/4 do tempo? No exemplo abaixo eu já verifiquei e existe índice pelos dois campos envolvidos um deles é a própria primary key. ALTER TABLE ONLY NotaItem ADD Constraint NotaItem_CodigoProduto_Produto_FK FOREGN KEY (CodigoProdutoItem REFERENCES Produto (CodigoInternoProduto) MATH FULL ON UPDATE RESTRICT ON DELETE RESTRICT; Posso até estar enganado, mas tem que haver uma explicação para este tempo absurdo ou alguma mancada muito grande. Abraços, Sergio Medeiros Santi __ Informação do NOD32 IMON 2719 (20071212) __ Esta mensagem foi verificada pelo NOD32 sistema antivírus http://www.eset.com.br ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral __ Informação do NOD32 IMON 2719 (20071212) __ Esta mensagem foi verificada pelo NOD32 sistema antivírus http://www.eset.com.br ___ 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] Off: Modelos de contratos
Olá! Como acredito que possa interessar se não a todos, mas a alguns, segue o link de um site com inúmeros modelos de contratos. Especificamente para trabalhar com PostgreSQL ou SGBDs eu não vi mas existem muitos outros que podemos adaptar para nosso caso, inclusive para ocnsultoria: http://www.sitecontabil.com.br/modelos_contrato.htm -- Ribamar FS - ribafs[ ]users.sourceforge.net http://www.ribafs.net ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Tempo excecivo ao restaurar banco - Mais a lguém se habilita?
Em 13/12/07, Sergio Medeiros Santi[EMAIL PROTECTED] escreveu: Pessoal: Ontem as 12 horas eu larguei a restauração novamente. As novas informações são as seguintes: Tempo total de restauração olhando pelos logs registrados: 14:03 (14 horas!) Tempo total da aplicação da constraint listada abaixo: 12:13 (12 horas!!!) Olha eu agradeço as sugestões de fazer backup físico, das informações de tempo de outros usuários, mas eu continuo achando que tem algo errado no meu caso. Uma única constraint consumindo 12 horas de um total de 14 horas necessários! Acho demais. Outro fato interessante é que, dentro do que acompanhei da aplicação da constraint o consumo de processador é baixíssimo (menos de 10% em um Xeon 2.13), bem como apresenta baixo consumo de memória e baixa atividade de disco. Parece simplesmente que esta etapa da restauração está fazendo corpo mole, operação tartaruga. Também já citei o tamanho da base (30G ao fazer o backup e 21G após a restauração) e o número de registros das duas tabelas envolvidas (NotaItem com 20.000.000 de registros e Produto com 40.000 registros). Pelo nível técnico das discussões que acompanho nesta lista eu esperava algum questionamento, ou sugestão mais relacionado ao problemas, ou ao menos uma afirmação de que os tempos que citei são normais (o que não acredito). Alguém sabe me dizer o que justifica que uma única contraint consumir tanto tempo? A mesma tabela aplica outras constraints em muito menos tempo (NotaItem com 20.000.000 de registros e NotaFiscal com 1.400.000 registros) por exemplo, consome 4 minutos. Existe alguma forma de fazer um explain analyse de uma constraint? Pelo nível das discussões que tenho acompanhado estou estranhando a falta de comentários profundos sobre este caso que tenho estudado a uns 6 meses. Este caso me é bastante instigante e não consigo apenas me conformar com a situação. De tempos em tempo eu a retomo. Ou resolvo isto ou acho uma explicação plausível sobre o caso. Não pretendo concluir que este fato deva-se a Vontade de Deus e que devo me resignar. Não vou jogar isto para baixo do tapete! Sergio Medeiros Santi Você está certo em não jogar isso para debaixo do tapete. Vejamos algumas coisas: 1) O autovacuum está ligado durante a restauração? Se estiver desligue. 2) Rode um autovacuum FULL antes de fazer o DUMP e restaure novamente. Veja se sente alguma diferença; 3) Durante o restore, garanta que ninguém mais esteja acessando o banco para ter certeza de que não está havendo nenhum LOCK. 4) Não há explain para comandos DDL. Veja se isso lhe ajuda. Se não ajudar... então seria necessário começar a olhar para a estrutura desta tabela para ter algum palpite. Espero ter ajudado. Atenciosamente, Fábio Telles -- blog: http://www.midstorm.org/~telles/ e-mail / jabber: [EMAIL PROTECTED] ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Calcular dias úteis(excluir sabad os dom. e feriados)
Marcos Barbosa escreveu:
Em primeiro lugar verifique por que suas últimas mensagens estão
vindo sem o corpo da mensagem.
Quanto aos dias úteis você pode determinar facilmente o dia da
semana utilizando a função extract com 'dow':
SELECT '2007-12-01'::date+s.a
FROM generate_series(0,30,1) s(a)
WHERE extract('dow' FROM '2007-12-01'::date+s.a)
BETWEEN 1 AND 5;
Quanto aos feriados a coisa pode ou não se complicar.
Existem os feriados oficias (previstos em lei nos âmbitos
nacional, estadual e municipal), os de categoria profissional
(normalmente previstos nos acordos intersindicais), outros como
os bancários (determinados pelo BACEN) e os da BOVESPA, e outros
que são feriados de facto (você sabia que o Carnaval não é um
feriado nacional, nem estadual e somente alguns municípios
declaram ponto facultativo?).
A solução mais simples é criar uma tabela com os feriados que
você irá considerar e atualizá-la quando julgar necessário.
A solução mais geral envolve calcular os feriados móveis (vários
deles dependem da Páscoa cuja data pode ser determinada através
de uma rotina, por exemplo em PL/pgSQL) e através de uma função
do tipo SRF calcular os feriados de um dado período.
Osvaldo
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] formatação_Moeda.
REPLACE(TRIM(TO_CHAR(REPLACE(CAMPO, ''99G999D99'' ,'G', ' '))), ' ', '.'); VEJA O ERRO: ERROR: function replace(numeric, unknown, unknown, unknown) does not exist ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] A Revista se foi mas ficou algo
Caro Ribamar, acho que o fato da revista não ter dado certo, não significa que outras coisas interesantes não tenham acontecido. - Já está em fase de testes um planeta para o PostgreSQL acho que em breve deve entrar em operação. - Achamos alguém com experiência em Drupal para dar uma força para nós. Acho que você deveria participar deste processo junto. Acho que vale a pena continuar investindo nisso lá na lista dev. Gostaria de lhe agradecer pela provocação que fez com que as pessoas se mexessem um pouco. Com o Drupal no ar, poderemos ter um site realmente mais dinâmico e utilizar vários recursos interessantes. Mesmo que a revista não saia imediatamente (ninguém disse que não pode vir a acontecer...) teremos a chance de agregar uma maior quantidade de artigos e organiza-los de forma mais interessante. Então Ribamar, simbora colocar a mão nisso? []s Fábio Telles Em 13/12/07, Ribamar Sousa[EMAIL PROTECTED] escreveu: Olá! Por vários motivos a revista não vingou, mas ainda assim acho que valeu a iniciativa. Pelo menos para aprender que não vale a pena. E como me meti a aprender a usar o Drupal acabei realmente aprendendo e hoje consigo criar um portal profissional usando o PostgreSQL Vou fazer um pequeno relato da experiência que tive com o Drupal ao tentar aprender para criar o site da Revista. Bem, consegui criar o site e ressalte-se que a maior compatibilidade é com o MySQL, mas instalei no meu espaço com o PostgreSQL 7.4 e se tomarmos alguns cuidsdos funciona beleza com o PG. Detalhe: ele precisa do de um banco criado com UNICODE, pode ser usuário comum, só para o banco. Evitar a instalação de módulos de terceiros, a não ser que se tenha tempo, interesse e conhecimento de PHP para fazer a conversão dos códigos. Muita coisa funciona mas algumas poucas causam problema. Detalhe: o ideal é usar a versão 5.x, pois a 6 (beta ainda) ainda não é bem suportada em termos de módulos. Estou planejando usar o que aprendi para criar um site com algumas coisas que tenho aqui sobre PostgreSQL e lá reservarei um espaço para receber artigos do PG, com direito a comentários e outros recursos. Já estou criando um site para tratar somente do Drupal e outros. -- Ribamar FS - ribafs[ ]users.sourceforge.net http://www.ribafs.net ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral -- blog: http://www.midstorm.org/~telles/ e-mail / jabber: [EMAIL PROTECTED] ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Configuração de servidor para co mpra
2007/12/13, Fernando de Oliveira [EMAIL PROTECTED]: - PostgreSQL: bases pequenas de até 1 giga ( várias) […] - Mysql para bases pequenas , email etc Evite. Tente concentrar em PostgreSQL. Por exemplo, correio eletrônico pode ficar no Archiveopteryx http://archiveopteryx.org./. Poderiam me sugerior a configuração recomendada? ( Levando em consideração custo benefício ) Alguns pontos: Memória é mais importante que velocidade. Cache é mais importante que velocidade. Confiabilidade é melhor que velocidade. Múltiplos processadores (núcleos) são melhores que velocidade. RAID 10 com discos de lotes diferentes de cada lado dos espelhos, discos SCSI ou SAS, memória com paridade, componentes bem suportados pelo SO — a HP e a IBM inclusive suportam Debian… Mais uma pergunta, é melhor eu ter dois servidores replicados (humildes) ou ter apenas um robusto ? Se você tiver condições de cuidar deles, dois. Se o tempo estiver curto para fazer uma boa administração de sistemas, é melhor ter um bem cuidado. -- +55 (11) 5685 2219 xmpp:[EMAIL PROTECTED] +55 (11) 9406 7191 Yahoo!: ymsgr:sendIM?lgcdutra +55 (11) 3040 7300 ICQ/AIM: aim:GoIM?screenname=61287803 MSN: msnim:[EMAIL PROTECTED] ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Configuração de servidor para com pra
Desculpa se estou sendo chato mas acho isso uma pergunta mais pertinente a uma lista de linux como um todo, aí você envolve várias coisas que entram em concorrência de processamento/memória/espaço em disco e isso seria legal ser abordado em listas mais pertinentes... Mas te digo uma coisa, não enfia email/sgbd/web em uma máquina só, é tiro no pé Leandro. Fernando de Oliveira escreveu: Olá a todos, Estou precisando comprar um servidor para rodar: - SO: to pensando no Debian. - Apache com PHP - DNS - PostgreSQL: bases pequenas de até 1 giga ( várias) - Email - Mysql para bases pequenas , email etc A carga do servidor, inicialmente seria de uns 10 domínios com aplicações em html/php. Acho que dificilmente passaria de 100 domínios. As bases do Postgresql, a maioria seriam bases pequenas de até 50 megas, algumas ( no máximo 5 ) com até 500 megas. Sobre usuários simultâneos, acredito que deveria atender até 30 sei lá. Bom, sei que rodar isso tudo em uma máquina seria complicado em um ambiente com muitos usuários simultaneos, bases de dados maiores, mas inicialmente, serão poucos usuários simultâneos. Poderiam me sugerior a configuração recomendada? ( Levando em consideração custo benefício ) Mais uma pergunta, é melhor eu ter dois servidores replicados (humildes) ou ter apenas um robusto ? Bom, gostaria da opinião geral de vocês sobre qual ambiente ideal para atender a estes requisitos, levando em consideraão mais uma vez, custo benefício, hehehe. ps - Desculpem o longo texto. []s Fernando de Oliveira ___ 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] Tempo excecivo ao restaurar banco - M ais alguém se habilita?
Olá, Olhando um pouco no histórico da lista performance foi sugerido que se aumentasse a memoria utilizada para a criação de indices (maintenance_work_mem) em uma maquina com 2G de memoria foi sugerido algo assim: shared_buffers = 2 maintenance_work_mem = 256000 infelizmente não sei o resultado pois apararentementaa pessoa que estava com o problema não postou se isso resolveu Espero que isto ajude. ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] formatação_Moeda.
altere a posição do to_char ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
[pgbr-geral] 25gb de imagem, isso presta?
Pessoal, preciso colocar 25gb de imagem no postgre, isso vai dar certo? E vai continuar entrando mais imagens a cada dia, será que é melhor colocar dentro ou fora, se algum tiver bastante experiencia com Postgres e Delphi e poder me dar uma força, ficaria grato. Meu email: [EMAIL PROTECTED] Obrigado =) ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
[pgbr-geral] http://explain-analyze.info/
Olá, pessoal Alguém está conseguindo usar? []s ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] A Revista se foi mas ficou algo
Em 13/12/07, Fabio Telles[EMAIL PROTECTED] escreveu: Caro Ribamar, acho que o fato da revista não ter dado certo, não significa que outras coisas interesantes não tenham acontecido. - Já está em fase de testes um planeta para o PostgreSQL acho que em breve deve entrar em operação. - Achamos alguém com experiência em Drupal para dar uma força para nós. Acho que você deveria participar deste processo junto. Eu gostaria de colaborar sim. Acho que vale a pena continuar investindo nisso lá na lista dev. Sabe porque mandei esta mensagem para cá e não para lá? Sinceramente por não ter percedido nenhuma repercussão por lá. Gostaria de lhe agradecer pela provocação que fez com que as pessoas se mexessem um pouco. Com o Drupal no ar, poderemos ter um site realmente mais dinâmico e utilizar vários recursos interessantes. Mesmo que a revista não saia imediatamente (ninguém disse que não pode vir a acontecer...) Acontece que um ou dois colegas (acho que foi o Roberto) levantaram umas questões negativas sobre uma revista e eu também percebo assim. Mas eu acho que um CMS como o Drupal poderá dinamizar e aumentar os recursos da comunidade: facilitando o acesso, a administração e oferecendo recursos que hoje ou não existem ou são mais lentos. teremos a chance de agregar uma maior quantidade de artigos e organiza-los de forma mais interessante. Então Ribamar, simbora colocar a mão nisso? Bem, minha intenção realmente é a de colaborar, pois tanto gosto de escrever quanto de desenvolver portais com o Joomla e agora, graças à revista, com o Drupal. -- Ribamar FS - ribafs[ ]users.sourceforge.net http://www.ribafs.net ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] http://explain-analyze.info/
Opa, Depois de algumas tentativas consegui usar. []s 2007/12/13, jota. comm [EMAIL PROTECTED]: Olá, pessoal Alguém está conseguindo usar? []s ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Tempo excecivo ao restaurar banco - M ais alguém se habilita?
Pessoal, vou responder meu prprio e-mail para evitar responder um a um. Desde j o meu obrigado a todos. Eu particularmente gosto muito deste trabalho investigativo. Normalmente quando descobrimos o que houve percebemos que possvel usar a descoberta em outros pontos com expressivos resultados. Infelizmente o PG anda tem alguns mistrios a resolver. O principal deles desenvolver um configurador que reuna informaes sobre o hardware e sugira uma configurao razovel. Isto teria me ajudado bastante quando comecei com o PG. Pelo que olhei das apresentaes do PGCon a coisa continua mais ou menos igual, no existe cincia nisto, mas alguma recomendaes (poucas infelizmente). Bem voltando ao assunto. Eu no eliminei a constraint e a recriei porque acredito que ela sonsumir o mesmo tempo que levou no restore. Configurei o postgres.conf para registrar tudo com mais de 500 ms e a criao desta constraint est l, bem clara, com os valores que forneci anteriormente. Seguem algumas respostas a perguntas que me foram feitas: - Dickson. No h nada rodando no servidor, alm do restore. O servidor est dedicado a este teste. - Cludio. No testei eliminar e recriar a constraint, mas tambm tenho uma forte suspeita de que por algum motivo ele no esteja usando os ndices, uma vez que os dois so bastante explcitos, sendo um a pk. - Leandro. O tempo de backup de 1 hora e de vacuum analyse de 4 horas. Como o cliente fica 8 horas fechado o tempo est sendo suficiente. Por outro lado eu tenho achado to estimulante este caso que estou preferindo dividir minhas pesquisas, concluses e dvidas com a lista do que invocar algum guru. Contudo no tenho nenhum problema com isso e j usei-os em alguma ocasies onde no havia tempo para aprender ou para resolver o problema. - Evandro. No alterei o restrict para noaction porque achava que eram a mesma coisa. Acho que vou testar isto antes de dropar a constraint e recri-la. - Fernando. Na verdade a estrategia de backup funciona bem o problema o restore. Felizmente no tive a necessidade de restaurar foradamente o banco, s no consigo engolir que de 14 horas, 12 foram consumidas apenas por uma constraint. No me parece ser uma referncia circular porque o treco demora mas termina e nada registrado no log que pudesse me levar a acreditar nisto. - Fbio. O autovacuum no utilizado, mas diariamente disparado um backup seguido de um vacuum analyse. Originalmente era usado o vacuum full, mas este foi abandonado porque em algumas oportundades ele no terminava e o banco ficava travado para os usurio no dia seguinte. O que tenho procurado fazer um backup seguido de restore com alguma periodicidade. Alias este procedimento que me fez questionar esta aplicao de constraint absurdamente lenta. - Luiz. Estou usando 32M em shared_buffers e 16M em maintenance_work_mem. Bem gente era isto vou usar todas estas consideraes para novos teste assim que tiver novidades eu posto. Outra coisa. No sei se esta minha idia de reunir tudo num nico e-mail foi muito boa. A idia era sintetizar tudo e evitar repetir consideraes. Abraos a todos, Sergio Medeiros Santi Sergio Medeiros Santi escreveu: Pessoal: Ontem as 12 horas eu larguei a restaurao novamente. As novas informaes so as seguintes: Tempo total de restaurao olhando pelos logs registrados: 14:03 (14 horas!) Tempo total da aplicao da constraint listada abaixo: 12:13 (12 horas!!!) Olha eu agradeo as sugestes de fazer backup "fsico", das informaes de tempo de outros usurios, mas eu continuo achando que tem algo errado no meu caso. Uma nica constraint consumindo 12 horas de um total de 14 horas necessrios! Acho demais. Outro fato interessante que, dentro do que acompanhei da aplicao da constraint o consumo de processador baixssimo (menos de 10% em um Xeon 2.13), bem como apresenta baixo consumo de memria e baixa atividade de disco. Parece simplesmente que esta etapa da restaurao est fazendo corpo mole, operao tartaruga. Tambm j citei o tamanho da base (30G ao fazer o backup e 21G aps a restaurao) e o nmero de registros das duas tabelas envolvidas (NotaItem com 20.000.000 de registros e Produto com 40.000 registros). Pelo nvel tcnico das discusses que acompanho nesta lista eu esperava algum questionamento, ou sugesto mais relacionado ao problemas, ou ao menos uma afirmao de que os tempos que citei so normais (o que no acredito). Algum sabe me dizer o que justifica que uma nica contraint consumir tanto tempo? A mesma tabela aplica outras constraints em muito menos tempo (NotaItem com 20.000.000 de registros e NotaFiscal com 1.400.000 registros) por exemplo, consome 4 minutos. Existe alguma forma de fazer um explain analyse de uma constraint? Pelo nvel das discusses que tenho acompanhado estou estranhando a falta de comentrios "profundos" sobre este caso que tenho estudado a uns 6 meses. Este caso me bastante instigante e no consigo apenas me conformar com a situao. De tempos em tempo eu a retomo. Ou resolvo isto ou acho uma explicao plausvel
Re: [pgbr-geral] 25gb de imagem, isso presta?
Olá, Uma dica. Você pode olhar os slides da palestra do Diogo Biazus do último PGCon, ele apresentou uma palestra exatamente sobre este assunto. O endereço é: http://www.postgresql.org.br/Palestras_do_PGCon_Brasil_2007 []s 2007/12/13, Claudio Rogerio Carvalho Filho [EMAIL PROTECTED]: Pessoal, preciso colocar 25gb de imagem no postgre, isso vai dar certo? E vai continuar entrando mais imagens a cada dia, será que é melhor colocar dentro ou fora, se algum tiver bastante experiencia com Postgres e Delphi e poder me dar uma força, ficaria grato. Meu email: [EMAIL PROTECTED] Obrigado =) ___ 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] formatação_Moeda.
Marcelo escreveu: REPLACE(TRIM(TO_CHAR(REPLACE(CAMPO, ''99G999D99'' ,'G', ' '))), ' ', '.'); VEJA O ERRO: ERROR: function replace(numeric, unknown, unknown, unknown) does not exist Veja se ajuda: bdteste=# SELECT ltrim(to_char(12345.67,'999.999.999.999D99'),' .'); ltrim --- 12.345,67 (1 registro) Osvaldo ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] 25gb de imagem, isso presta?
Claudio Rogerio Carvalho Filho wrote: Pessoal, preciso colocar 25gb de imagem no postgre, isso vai dar certo? E vai continuar entrando mais imagens a cada dia, será que é melhor colocar dentro ou fora, se algum tiver bastante experiencia com Postgres e Delphi e poder me dar uma força, ficaria grato. Pelo visto você não esteve na PG-Con ou, se esteve, não assistiu a apresentação do Diogo Biazus. Veja Preciso armazenar arquivos no banco. O que fazer? em: http://www.postgresql.org.br/Palestras_do_PGCon_Brasil_2007 Osvaldo -- View this message in context: http://www.nabble.com/25gb-de-imagem%2C-isso-presta--tp14322720p14323386.html Sent from the PostgreSQL - Brasil mailing list archive at Nabble.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] 25gb de imagem, isso presta?
Claudio Rogerio Carvalho Filho escreveu: Pessoal, preciso colocar 25gb de imagem no postgre, isso vai dar certo? E vai continuar entrando mais imagens a cada dia, será que é melhor colocar dentro ou fora, se algum tiver bastante experiencia com Postgres e Delphi e poder me dar uma força, ficaria grato. Meu email: [EMAIL PROTECTED] Obrigado =) Coloque pra fora, meu filho =) Se forem 25GB em uma única imagem, armazene apenas o path ... Mas se forem várias pequenas você pode armazenar como bytea. O limite do postgres é de 2GB, se não me engano. -- []´s, André Volpato Ecom Tecnologia LTDA - Análise e Desenvolvimento [EMAIL PROTECTED] ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] 25gb de imagem, isso presta?
2007/12/13, Claudio Rogerio Carvalho Filho [EMAIL PROTECTED]: Pessoal, preciso colocar 25gb de imagem no postgre, isso vai dar certo? E vai continuar entrando mais imagens a cada dia, será que é melhor colocar dentro ou fora, se algum tiver bastante experiencia com Postgres e Delphi e poder me dar uma força, ficaria grato. Vide apresentação do Diogo na Conferência! -- +55 (11) 5685 2219 xmpp:[EMAIL PROTECTED] +55 (11) 9406 7191 Yahoo!: ymsgr:sendIM?lgcdutra +55 (11) 3040 7300 ICQ/AIM: aim:GoIM?screenname=61287803 MSN: msnim:[EMAIL PROTECTED] ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Configuração de servidor para com pra
Prezado Leandro D., Você tem todo o direito de ser chato, mas resolvi perguntar aqui porque tem muita gente, aliás a maioria trabalha em plataforma Linux inclusive em empresas de host. E por isso gostaria de discutir neste espaço, quem concorda com você, é só não responder que o assunto se encerra e eu vou para um fórum de linux discutir. []s Fernando - Original Message - From: Leandro Damascena [EMAIL PROTECTED] To: Comunidade PostgreSQL Brasileira pgbr-geral@listas.postgresql.org.br Sent: Thursday, December 13, 2007 2:34 PM Subject: Re: [pgbr-geral] Configuração de servidor para compra Desculpa se estou sendo chato mas acho isso uma pergunta mais pertinente a uma lista de linux como um todo, aí você envolve várias coisas que entram em concorrência de processamento/memória/espaço em disco e isso seria legal ser abordado em listas mais pertinentes... Mas te digo uma coisa, não enfia email/sgbd/web em uma máquina só, é tiro no pé Leandro. Fernando de Oliveira escreveu: Olá a todos, Estou precisando comprar um servidor para rodar: - SO: to pensando no Debian. - Apache com PHP - DNS - PostgreSQL: bases pequenas de até 1 giga ( várias) - Email - Mysql para bases pequenas , email etc A carga do servidor, inicialmente seria de uns 10 domínios com aplicações em html/php. Acho que dificilmente passaria de 100 domínios. As bases do Postgresql, a maioria seriam bases pequenas de até 50 megas, algumas ( no máximo 5 ) com até 500 megas. Sobre usuários simultâneos, acredito que deveria atender até 30 sei lá. Bom, sei que rodar isso tudo em uma máquina seria complicado em um ambiente com muitos usuários simultaneos, bases de dados maiores, mas inicialmente, serão poucos usuários simultâneos. Poderiam me sugerior a configuração recomendada? ( Levando em consideração custo benefício ) Mais uma pergunta, é melhor eu ter dois servidores replicados (humildes) ou ter apenas um robusto ? Bom, gostaria da opinião geral de vocês sobre qual ambiente ideal para atender a estes requisitos, levando em consideraão mais uma vez, custo benefício, hehehe. ps - Desculpem o longo texto. []s Fernando de Oliveira ___ 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] 25gb de imagem, isso presta?
sim, vai dar certo se sua itenção é destruir tua rede, micro e banco de dados. Que pergunta mais estúpida. Claudio Rogerio Carvalho Filho [EMAIL PROTECTED] escreveu: Pessoal, preciso colocar 25gb de imagem no postgre, isso vai dar certo? E vai continuar entrando mais imagens a cada dia, será que é melhor colocar dentro ou fora, se algum tiver bastante experiencia com Postgres e Delphi e poder me dar uma força, ficaria grato. Meu email: [EMAIL PROTECTED] Obrigado =) ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral - Abra sua conta no Yahoo! Mail, o único sem limite de espaço para armazenamento! ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
[pgbr-geral] RES: 25gb de imagem, isso presta?
Meu conselho de sempre.coloque apenas um campo no banco apontando para o local + nome arquivo + extensao...ou apenas o caminho completo deixando as figuras fora do banco. Santiago NSR Informática -Mensagem original- De: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Em nome de Claudio Rogerio Carvalho Filho Enviada em: quinta-feira, 13 de dezembro de 2007 15:04 Para: pgbr-geral@listas.postgresql.org.br Assunto: [pgbr-geral] 25gb de imagem, isso presta? Pessoal, preciso colocar 25gb de imagem no postgre, isso vai dar certo? E vai continuar entrando mais imagens a cada dia, será que é melhor colocar dentro ou fora, se algum tiver bastante experiencia com Postgres e Delphi e poder me dar uma força, ficaria grato. Meu email: [EMAIL PROTECTED] Obrigado =) ___ 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] [pgbr-dev] command_string
Novamente mudando para a lista geral. Conforme o Euler já disse, aqui devem ser discutidos assuntos de postgres em geral. A lista dev é utilizada apenas para organização de nossa comunidade. On Dec 13, 2007 1:13 PM, Fernando Brombatti [EMAIL PROTECTED] wrote: Estou usando psql pq estou montando um script que manda email para uma galera aqui que diz que postgresql é ruim, com todas as querys do ERP que levarem mais de 3 minutos para rodar. Então a cada 60 segundo quero rodar um query que preparei... e mostrar para eles que o sistema que eles desenvolveram é que está ruim e não o SGBD. Problemas à parte, ele está truncando o sql (deve ser por votla desse 1kb mesmo). Utilize a configuração de logs do próprio postgres para alcançar seu objetivo. Em especial os seguintes parametros devam resolvert: redirect_stderr = on log_min_duration_statement = 3Min log_filename = 'pg.log' Procure no arquivo pg.log as consultas interessantes para sua pesquisa. Consulte o manual para maiores informações sobre os gerenciamento de logs. Se não tem como mudar, em qual versão ele deverá ser configurável? Não sei. Existem usuários com mais propriedade para responder esta questão nesta lista. Na verdade uma olhadela no @TODO deveria ser suficiente. O fato é que a constante PGBR_ACTIVITY_SIZE possui um valor inicial de 1024b e AFAIK é utilizada apenas para fins de estatisticas. Alterar o tamanho deste objeto e recompilar o postgres deveria funcionar, porém não é assim que as coisas funcionam, então é melhor esperar a geração do GUC pelo PGDG. Abraço! -Leo -- Leonardo Cezar PgConBrasil: dias 7-8 dezembro 2007 http://pgcon.postgresql.org.br ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] 25gb de imagem, isso presta?
On Dec 13, 2007 4:03 PM, Claudio Rogerio Carvalho Filho [EMAIL PROTECTED] wrote: Pessoal, preciso colocar 25gb de imagem no postgre, isso vai dar certo? E vai continuar entrando mais imagens a cada dia, será que é melhor colocar dentro ou fora, se algum tiver bastante experiencia com Postgres e Delphi e poder me dar uma força, ficaria grato. Esse tema foi discutido na pgcon com mais uma ótima apresentação do Sr. Biazus. Pelo jeito voce não esteve lá... É uma pena :-) Mas dá pra ter uma idéia do que foi visto lá acessando o repositório das palestras do evento: http://www.postgresql.org.br/Palestras_do_PGCon_Brasil_2007?action=AttachFiledo=gettarget=arquivos_no_banco.pdf Voltando a sua duvida, eu pensaria seriamente em trazer estas imagens para o disco. Abraço! -Leo -- Leonardo Cezar PgConBrasil: dias 7-8 dezembro 2007 http://pgcon.postgresql.org.br ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] formatação_Moeda.
Galera valeu pela força... 2007/12/13, Osvaldo Rosario Kussama [EMAIL PROTECTED]: Marcelo escreveu: REPLACE(TRIM(TO_CHAR(REPLACE(CAMPO, ''99G999D99'' ,'G', ' '))), ' ', '.'); VEJA O ERRO: ERROR: function replace(numeric, unknown, unknown, unknown) does not exist Veja se ajuda: bdteste=# SELECT ltrim(to_char(12345.67,'999.999.999.999D99'),' .'); ltrim --- 12.345,67 (1 registro) Osvaldo ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral -- Marcelo ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Tempo excecivo ao restaurar banco - M ais alguém se habilita?
Sergio Medeiros Santi escreveu: Pessoal, vou responder meu próprio e-mail para evitar responder um a um. Desde já o meu obrigado a todos. Eu particularmente gosto muito deste trabalho investigativo. Normalmente quando descobrimos o que houve percebemos que é possível usar a descoberta em outros pontos com expressivos resultados. Infelizmente o PG anda tem alguns mistérios a resolver. O principal deles é desenvolver um configurador que reuna informações sobre o hardware e sugira uma configuração razoável. Isto teria me ajudado bastante quando comecei com o PG. Pelo que olhei das apresentações do PGCon a coisa continua mais ou menos igual, não existe ciência nisto, mas alguma recomendações (poucas infelizmente). Bem voltando ao assunto. Eu não eliminei a constraint e a recriei porque acredito que ela sonsumirá o mesmo tempo que levou no restore. Configurei o postgres.conf para registrar tudo com mais de 500 ms e a criação desta constraint está lá, bem clara, com os valores que forneci anteriormente. Seguem algumas respostas a perguntas que me foram feitas: - Dickson. Não há nada rodando no servidor, além do restore. O servidor está dedicado a este teste. - Cláudio. Não testei eliminar e recriar a constraint, mas também tenho uma forte suspeita de que por algum motivo ele não esteja usando os índices, uma vez que os dois são bastante explícitos, sendo um a pk. - Leandro. O tempo de backup é de 1 hora e de vacuum analyse de 4 horas. Como o cliente fica 8 horas fechado o tempo está sendo suficiente. Por outro lado eu tenho achado tão estimulante este caso que estou preferindo dividir minhas pesquisas, conclusões e dúvidas com a lista do que invocar algum guru. Contudo não tenho nenhum problema com isso e já usei-os em alguma ocasiões onde não havia tempo para aprender ou para resolver o problema. - Evandro. Não alterei o restrict para noaction porque achava que eram a mesma coisa. Acho que vou testar isto antes de dropar a constraint e recriá-la. - Fernando. Na verdade a estrategia de backup funciona bem o problema é o restore. Felizmente não tive a necessidade de restaurar forçadamente o banco, só não consigo engolir que de 14 horas, 12 foram consumidas apenas por uma constraint. Não me parece ser uma referência circular porque o treco demora mas termina e nada é registrado no log que pudesse me levar a acreditar nisto. - Fábio. O autovacuum não é utilizado, mas diariamente é disparado um backup seguido de um vacuum analyse. Originalmente era usado o vacuum full, mas este foi abandonado porque em algumas oportundades ele não terminava e o banco ficava travado para os usuário no dia seguinte. O que tenho procurado fazer é um backup seguido de restore com alguma periodicidade. Alias é este procedimento que me fez questionar esta aplicação de constraint absurdamente lenta. - Luiz. Estou usando 32M em shared_buffers e 16M em maintenance_work_mem. Bem gente era isto vou usar todas estas considerações para novos teste assim que tiver novidades eu posto. Outra coisa. Não sei se esta minha idéia de reunir tudo num único e-mail foi muito boa. A idéia era sintetizar tudo e evitar repetir considerações. Abraços a todos, Sergio Medeiros Santi Sergio Medeiros Santi escreveu: Pessoal: Ontem as 12 horas eu larguei a restauração novamente. As novas informações são as seguintes: Tempo total de restauração olhando pelos logs registrados: 14:03 (14 horas!) Tempo total da aplicação da constraint listada abaixo: 12:13 (12 horas!!!) Olha eu agradeço as sugestões de fazer backup físico, das informações de tempo de outros usuários, mas eu continuo achando que tem algo errado no meu caso. Uma única constraint consumindo 12 horas de um total de 14 horas necessários! Acho demais. Outro fato interessante é que, dentro do que acompanhei da aplicação da constraint o consumo de processador é baixíssimo (menos de 10% em um Xeon 2.13), bem como apresenta baixo consumo de memória e baixa atividade de disco. Parece simplesmente que esta etapa da restauração está fazendo corpo mole, operação tartaruga. Também já citei o tamanho da base (30G ao fazer o backup e 21G após a restauração) e o número de registros das duas tabelas envolvidas (NotaItem com 20.000.000 de registros e Produto com 40.000 registros). Pelo nível técnico das discussões que acompanho nesta lista eu esperava algum questionamento, ou sugestão mais relacionado ao problemas, ou ao menos uma afirmação de que os tempos que citei são normais (o que não acredito). Alguém sabe me dizer o que justifica que uma única contraint consumir tanto tempo? A mesma tabela aplica outras constraints em muito menos tempo (NotaItem com 20.000.000 de registros e NotaFiscal com 1.400.000 registros) por exemplo, consome 4 minutos. Existe alguma forma de fazer um explain analyse de uma constraint? Pelo nível das discussões que
Re: [pgbr-geral] Configuração de servidor para co mpra
2007/12/13, Fernando de Oliveira [EMAIL PROTECTED]: Prezado Leandro D., Tem dois aqui! Você tem todo o direito de ser chato, mas resolvi perguntar aqui porque tem muita gente, aliás a maioria trabalha em plataforma Linux inclusive em empresas de host. Acho que você não entendeu. O que o Damascena quis dizer é que a questão é mais genérica que PostgreSQL, e ao mesmo tempo esta lista tem muita gente que não é de GNU/Linux. -- +55 (11) 5685 2219 xmpp:[EMAIL PROTECTED] +55 (11) 9406 7191 Yahoo!: ymsgr:sendIM?lgcdutra +55 (11) 3040 7300 ICQ/AIM: aim:GoIM?screenname=61287803 MSN: msnim:[EMAIL PROTECTED] ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Tempo excecivo ao restaurar banco - M ais alguém se habilita?
No testei o -1 no, mas que mal le pergunte, aplicar uma constraint gera alguma atualizao ou apenas valida a restrio? Abraos, Sergio Medeiros Santi Osvaldo Rosario Kussama escreveu: Ningum comentou mas voc tentou utilizar a opo -1 (ou --single-transaction)? http://www.postgresql.org/docs/8.2/interactive/app-pgrestore.html Osvaldo ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral __ Informao do NOD32 IMON 2721 (20071213) __ Esta mensagem foi verificada pelo NOD32 sistema antivrus http://www.eset.com.br ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Tempo excecivo ao restaurar banco - M ais alguém se habilita?
Sergio Medeiros Santi escreveu: - Fernando. Na verdade a estrategia de backup funciona bem o problema é o restore. Felizmente não tive a necessidade de restaurar forçadamente o banco, só não consigo engolir que de 14 horas, 12 foram consumidas apenas por uma constraint. Não me parece ser uma referência circular porque o treco demora mas termina e nada é registrado no log que pudesse me levar a acreditar nisto. O Fernando Saimon sugeriu você criar a constraint primeiro e depois subir os dados para ver o resultado, você fez isso? Se fez por favor desconsidere esse e-mail, apenas citei pois você não explicou se fez ou não... Leandro Damascena ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] 25gb de imagem, isso presta?
Paulo Saimon Ramos escreveu: sim, vai dar certo se sua itenção é destruir tua rede, micro e banco de dados. Que pergunta mais estúpida. ACHO que para o bem geral podemos discordar de pensamentos/idéias do próximo de uma forma mais produtiva (... educada ...) e manter o foco na solução/dúvida/idéia... :-D Leandro Damascena. ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
