Re: [pgbr-geral] [pbgr-geral] ADD COLUMN
Bem, nos meus testes auditando a tabela que adiciona uma nova coluna com default não gera o evento update, então suponho ser mais 'barato' esta abordagem. para informações mais técnicas, vide os mestres da lista. Em 30 de novembro de 2012 02:08, Danilo Silva danilo.dsg.go...@gmail.comescreveu: Pessoal, Preciso incluir um novo campo em uma tabela, esse campo é do tipo integer. Preciso que todos registros recebam o valor 1 referente a esse novo campo. Minha dúvida está em saber qual dos comandos abaixo seria mais rápido, ou não faz diferença? [1] ALTER TABLE tabela ADD COLUMN novo_campo integer; UPDATE tabela SET novo_campo = 1; ou [2] ALTER TABLE tabela ADD COLUMN novo_campo integer DEFAULT 1; Lembrando que tanto faz em deixar ou não o campo com um valor DEFAULT, mas como a tabela já possui registros (atualmente está com 450 de registros), preciso que o valor seja 1 para os registros já existentes. []s Danilo ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral -- Anselmo M. Silva ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] [pbgr-geral] ADD COLUMN
Pessoal, Preciso incluir um novo campo em uma tabela, esse campo é do tipo integer. Preciso que todos registros recebam o valor 1 referente a esse novo campo. Minha dúvida está em saber qual dos comandos abaixo seria mais rápido, ou não faz diferença? [1] ALTER TABLE tabela ADD COLUMN novo_campo integer; UPDATE tabela SET novo_campo = 1; ou [2] ALTER TABLE tabela ADD COLUMN novo_campo integer DEFAULT 1; Lembrando que tanto faz em deixar ou não o campo com um valor DEFAULT, mas como a tabela já possui registros (atualmente está com 450 de registros), preciso que o valor seja 1 para os registros já existentes. []s Danilo -- Anselmo M. Silva O link da discursão abaixo explana melhor... http://postgresql.1045698.n5.nabble.com/Alter-table-com-campo-default-td2028776.html -- Anselmo M. Silva ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] [pbgr-geral] ADD COLUMN
Em 30-11-2012 07:59, Anselmo Silva escreveu: Bem, nos meus testes auditando a tabela que adiciona uma nova coluna com default não gera o evento update, então suponho ser mais 'barato' esta abordagem. para informações mais técnicas, vide os mestres da lista. E por causa disso, existe uma diferença lógica: Ao inserir nova coluna, as linhas existentes não terão o novo valor DEFAULT, somente novas linhas. Em 30 de novembro de 2012 02:08, Danilo Silva danilo.dsg.go...@gmail.com mailto:danilo.dsg.go...@gmail.com escreveu: Pessoal, Preciso incluir um novo campo em uma tabela, esse campo é do tipo integer. Preciso que todos registros recebam o valor 1 referente a esse novo campo. Minha dúvida está em saber qual dos comandos abaixo seria mais rápido, ou não faz diferença? [1] ALTER TABLE tabela ADD COLUMN novo_campo integer; UPDATE tabela SET novo_campo = 1; ou [2] ALTER TABLE tabela ADD COLUMN novo_campo integer DEFAULT 1; Note que na situação [1] você tem dois comandos em uma linha. Logo, a situação [1] será mais demorada que a [2], uma vez que a [1] é exatamente a [2] mais um UPDATE. Lembrando que tanto faz em deixar ou não o campo com um valor DEFAULT, mas como a tabela já possui registros (atualmente está com 450 de registros), preciso que o valor seja 1 para os registros já existentes. Então você precisará do UPDATE. Use sua linha [1]. []s __ Flavio Henrique A. Gurgel Líder de Projetos Especiais Consultoria, Projetos Treinamentos 4LINUX Tel1: +55-11.2125-4747 ou 2125-4748 www.4linux.com.br email: fla...@4linux.com.br __ FREE SOFTWARE SOLUTIONS ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] HA Postgres
2012/11/29 Eduardo Rodrigues edua...@ookle.com.br Boa tarde Pessoal, irei montar um ambiente de alta disponibilidade do PostGreSQL, e pensei que a melhor solução seria montar um ambiente utilizando o Corosync (servidor ativo e passivo) e o FreeNAS para armazenar os dados. Gostaria de saber se há algum modo melhor para montar um ambiente de HA? Cara, vai depender do seu ambiente. Em muitos casos apenas a replicação nativa Hot Standby (9.0+) é suficiente, deixando o processo de promoção de slave manual. Em outros, usa-se o Corosync+Pacemaker para gerenciar a troca de IP e/ou o promoção do master (em muitos casos promote automático não é uma boa). -- Matheus de Oliveira Analista de Banco de Dados PostgreSQL Dextra Sistemas - MPS.Br nível F! www.dextra.com.br/postgres ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] HA Postgres
2012/11/29 Luiz Carlos L. Nogueira Jr. lcnogueir...@gmail.com Replicação do Postgres e Slony ou pgpool Em 29 de novembro de 2012 16:35, Eduardo Rodrigues edua...@ookle.com.brescreveu: Boa tarde Pessoal, irei montar um ambiente de alta disponibilidade do PostGreSQL, e pensei que a melhor solução seria montar um ambiente utilizando o Corosync (servidor ativo e passivo) e o FreeNAS para armazenar os dados. Gostaria de saber se há algum modo melhor para montar um ambiente de HA? Obrigado pela ajuda Eu não usaria o PGPool para HA. Ele tem várias funcionalidades bacanas, mas usar ele apenas para alta disponibilidade eu acho que é um overhead a mais que pode ser facilmente evitado. Agora, se quiser balanceamento de carga este é uma boa pedida. -- Matheus de Oliveira Analista de Banco de Dados PostgreSQL Dextra Sistemas - MPS.Br nível F! www.dextra.com.br/postgres ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Dump muito grande - Opções para diminuir - Demora
Em 29 de novembro de 2012 11:20, Luiz Carlos L. Nogueira Jr. lcnogueir...@gmail.com escreveu: Eu também tive esse problema em dumps de banco de imagens. Ele fica bem maior do que o SO mostra. Ele vai ser demorado mesmo. Minha infra é MUITO boa, o banco no SO tem +- 120GB e qdo fizemos o dump plain ele fica com mais de 400GB (não sei o valor pq estourou a partição de dumps). Só deu na partição com o -Fc mesmo. Usei a compressão (-Z ) e não valeu o custo/benefício de tempo/tamanho. Então, nem se preocupe vai demorar mesmo. Como já falaram anteriormente Acharia melhor vc replicar mesmo, pois a carga na rede será beeem menor que vc ficar mandando esse dump inteiro. BOA SORTE!! Aê galera. Obrigado a todos pelas dicas consegui resolver o tamanho..Ficou agora com o tamanho quase igual ao do banco. Pelo fato do banco ter imagens de geoprocessamento a demora foi inevitável mas já resolveu meu problema de tamanho. postgres@prod:/postgresql/backup$ ls -lah total 190G drwxr-xr-x 2 postgres postgres 4.0K 2012-11-29 09:19 ./ drwx-- 8 postgres postgres 4.0K 2012-06-14 16:00 ../ -rw-r--r-- 1 postgres postgres 48G 2012-11-29 14:56 bd_Alagoas.dump.gz Em 29 de novembro de 2012 11:01, Flávio Alves Granato flavio.gran...@gmail.com escreveu: Emerson Martins writes: Flavio Alves. Minhas sinceras desculpas para você e para todos que estão recebendo os e-mails, deve estar havendo algum problema com minha ferramenta de e-mail como você mesmo falou, pois e dessa forma que estou fazendoo qual estou enviando.Minha intenção não foi ofender, e claro tenho sempre a mente aberta para aprender e reconheço que a intenção da lista é ajudar.Então mais uma vez desculpas; Se alguém..Deve ser ter alguma configuração o qual eu nao sei na parte da lista. Emerson Martins Sem problema. Desculpas aceitas, boa sorte na solução dos seus problemas. -- Flávio Alves Granato gpg: 968F:A938:70B9:82C7:5198:2C74:13CB:2C25:EF1E:726D ___ 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] dúvida sobre tamanho de tabela
Criei uma tabela de log que é populada via trigger, mas ela está ficando muito grande, cerca de 7GB, exclui quase todos os registros desta tabela, deixando apenas os mais recentes, mas a tabela continua com o mesmo tamanho. Obs.: Meu postgres é o 8.4 e estou utilizando o pgadmin para visualizar estas estatísticas, e já rodei o VACUUM ANALYZE nesta tabela após as exclusão dos registros. O que devo fazer para diminuir o tamanho desta tabela? Atenciosamente, Alessandro Lima email grandegoia...@gmail.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] dúvida sobre tamanho de tabela
Em 30 de novembro de 2012 11:50, Alessandro Lima grandegoia...@gmail.comescreveu: Criei uma tabela de log que é populada via trigger, mas ela está ficando muito grande, cerca de 7GB, exclui quase todos os registros desta tabela, deixando apenas os mais recentes, mas a tabela continua com o mesmo tamanho. Obs.: Meu postgres é o 8.4 e estou utilizando o pgadmin para visualizar estas estatísticas, e já rodei o VACUUM ANALYZE nesta tabela após as exclusão dos registros. O que devo fazer para diminuir o tamanho desta tabela? Atenciosamente, Alessandro Lima email grandegoia...@gmail.com Olá, Vacuum analyze ou vacuum full? Vide: http://www.postgresql.org/docs/8.3/static/sql-vacuum.html Abraços, Eduardo Alexandre ___ 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 tamanho de tabela
Em 30-11-2012 11:50, Alessandro Lima escreveu: Criei uma tabela de log que é populada via trigger, mas ela está ficando muito grande, cerca de 7GB, exclui quase todos os registros desta tabela, deixando apenas os mais recentes, mas a tabela continua com o mesmo tamanho. Então você usou DELETE. Normal. Não existe encolhimento de tabela no PostgreSQL. Bom, você queria uma tabela de log, conseguiu! Ela só cresce... Obs.: Meu postgres é o 8.4 e estou utilizando o pgadmin para visualizar estas estatísticas, e já rodei o VACUUM ANALYZE nesta tabela após as exclusão dos registros. VACUUM ANALYZE não diminui espaço em disco. Porém, o espaço ocupado pelas linhas removidas poderá ser utilizado por novos INSERTs. O que devo fazer para diminuir o tamanho desta tabela? VACUUM FULL ou CLUSTER. Na versão 8.4, prefira CLUSTER que é mais rápido. Ou faça um dump/restore da tabela que dá na mesma. []s __ Flavio Henrique A. Gurgel Líder de Projetos Especiais Consultoria, Projetos Treinamentos 4LINUX Tel1: +55-11.2125-4747 ou 2125-4748 www.4linux.com.br email: fla...@4linux.com.br __ FREE SOFTWARE SOLUTIONS ___ 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 tamanho de tabela
Olá, Em 30 de novembro de 2012 11:50, Alessandro Lima grandegoia...@gmail.comescreveu: Criei uma tabela de log que é populada via trigger, mas ela está ficando muito grande, cerca de 7GB, exclui quase todos os registros desta tabela, deixando apenas os mais recentes, mas a tabela continua com o mesmo tamanho. Obs.: Meu postgres é o 8.4 e estou utilizando o pgadmin para visualizar estas estatísticas, e já rodei o VACUUM ANALYZE nesta tabela após as exclusão dos registros. O que devo fazer para diminuir o tamanho desta tabela? O vacuum não vai liberar o espaço a no SO, por isso sua tabela mantem o mesmo tamanho e cada vez cresce mais. O Analyze apenas atualiza as estatísiticas. Para liberar espaço você pode usar o comando TRUNCATE TABLE ou pensar em executar um VACUUM FULL na tabela. Atenciosamente, Alessandro Lima email grandegoia...@gmail.com ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral Abraços -- 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
Re: [pgbr-geral] dúvida sobre tamanho de tabela
Em 30-11-2012 11:58, JotaComm escreveu: O que devo fazer para diminuir o tamanho desta tabela? O vacuum não vai liberar o espaço a no SO, por isso sua tabela mantem o mesmo tamanho e cada vez cresce mais. O Analyze apenas atualiza as estatísiticas. Para liberar espaço você pode usar o comando TRUNCATE TABLE ou pensar em executar um VACUUM FULL na tabela. Só toma cuidado com o TRUNCATE. Ele limpará *tudo* da tabela. Acho que o colega da pergunta original quer remover *parte* dos registros, então, tem de ser DELETE mesmo. Outras alternativas: 1) Criar uma tabela a partir da original, usando INSERT...SELECT...WHERE e depois remover a original com DROP TABLE. 2) Pra manter esse banco com facilidade, particionar essa tabela de log é vantajoso com certeza. []s __ Flavio Henrique A. Gurgel Líder de Projetos Especiais Consultoria, Projetos Treinamentos 4LINUX Tel1: +55-11.2125-4747 ou 2125-4748 www.4linux.com.br email: fla...@4linux.com.br __ FREE SOFTWARE SOLUTIONS ___ 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 tamanho de tabela
Em 30 de novembro de 2012 12:03, Flavio Henrique Araque Gurgel fla...@4linux.com.br escreveu: 2) Pra manter esse banco com facilidade, particionar essa tabela de log é vantajoso com certeza. Neste caso, o procedimento de particionamento com a tabela já populada seria o mesmo criando as tabelas do zero? Pois o meu conhecimento sobre particionamento é através de herança, criando gatilhos na tabela pai para direcionar os registros paras as tabelas filhas, mas se a tabela pai já está populada, seria necessário mover esses registros (através de inserts eu acho) para as tabelas filhas? []s Danilo ___ 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 tamanho de tabela
Em 30-11-2012 13:26, Danilo Silva escreveu: 2) Pra manter esse banco com facilidade, particionar essa tabela de log é vantajoso com certeza. Neste caso, o procedimento de particionamento com a tabela já populada seria o mesmo criando as tabelas do zero? Pois o meu conhecimento sobre Quase o mesmo. particionamento é através de herança, criando gatilhos na tabela pai para direcionar os registros paras as tabelas filhas, mas se a tabela Isso mesmo. Que bom que você já conhece. pai já está populada, seria necessário mover esses registros (através de inserts eu acho) para as tabelas filhas? Sim, é necessário. Mas como as linhas existentes, pelo que entendi, você vai guardar por um tempo apenas, você também pode transformar a tabela existente em uma das filhas. Quando os dados dela se tornarem irrelevantes pra você, é só dropar. []s __ Flavio Henrique A. Gurgel Líder de Projetos Especiais Consultoria, Projetos Treinamentos 4LINUX Tel1: +55-11.2125-4747 ou 2125-4748 www.4linux.com.br email: fla...@4linux.com.br __ FREE SOFTWARE SOLUTIONS ___ 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 tamanho de tabela
Em 30 de novembro de 2012 13:28, Flavio Henrique Araque Gurgel fla...@4linux.com.br escreveu: Em 30-11-2012 13:26, Danilo Silva escreveu: 2) Pra manter esse banco com facilidade, particionar essa tabela de log é vantajoso com certeza. Neste caso, o procedimento de particionamento com a tabela já populada seria o mesmo criando as tabelas do zero? Pois o meu conhecimento sobre Quase o mesmo. particionamento é através de herança, criando gatilhos na tabela pai para direcionar os registros paras as tabelas filhas, mas se a tabela Isso mesmo. Que bom que você já conhece. pai já está populada, seria necessário mover esses registros (através de inserts eu acho) para as tabelas filhas? Sim, é necessário. Mas como as linhas existentes, pelo que entendi, você vai guardar por um tempo apenas, você também pode transformar a tabela existente em uma das filhas. Quando os dados dela se tornarem irrelevantes pra você, é só dropar. Opa, valeu Flavio. []s Danilo ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Dump muito grande - Opções para diminuir - Demora
Pessoal...estou com uma necessidade de conectar o vb 6 com o postgres 9...ja criar um odbc para ele e ta ok..mas nao consigo conectar de dentro do codigo vb com a sintaxe do conn.open driver=nome do alias alguem pode me ajudar? Rodrigo ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Dump muito grande - Opções para diminuir - Demora
Em 30 de novembro de 2012 17:18, rodrigo systemas rodrigo.syste...@gmail.com escreveu: Pessoal...estou com uma necessidade de conectar o vb 6 com o postgres 9...ja criar um odbc para ele e ta ok..mas nao consigo conectar de dentro do codigo vb com a sintaxe do conn.open driver=nome do alias alguem pode me ajudar? Rodrigo, peço que inicie outra thread, mandando um email com a sua dúvida, sem responder esta thread, pois ela tem a ver com outro problema e não com programação e conexão com o postgresql... é só mandar outro email para a lista com a sua dúvida, assim fica fácil de quem tiver o mesmo problema que você acompanhar o que acontece na tentativa de te ajudar... abraços, Flávio Granato ___ 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 tamanho de tabela
On 30-11-2012 13:38, Alessandro Lima wrote: Agora surgiu outra dúvida, se eu excluir apenas os valores de algumas colunas (colunas grandes como text), o vacuum full também diminuiria o tamnanho da tabela? Pode ser que sim. Tudo vai depender do quão grande são os seus campos. Vide a estratégia TOAST para detalhes. Desaconselho o uso do VF em favor do autovacuum + VACUUM manual (se necessário). -- Euler Taveira de Oliveira - Timbira http://www.timbira.com.br/ PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] dúvida sobre tamanho de tabela
Em 30 de novembro de 2012 19:34, Euler Taveira eu...@timbira.com escreveu: [...] Desaconselho o uso do VF em favor do autovacuum + VACUUM manual (se necessário). Nem a nova implementação do VF é recomendada, claro que se tiver *janela de manutenção* para tal atividade ??? Att, -- Fabrízio de Royes Mello Consultoria/Coaching PostgreSQL Blog sobre TI: http://fabriziomello.blogspot.com Perfil Linkedin: http://br.linkedin.com/in/fabriziomello Twitter: http://twitter.com/fabriziomello ___ 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 tamanho de tabela
Alessandro, Minha sugestão é clusterizar a tabela com o primary key dela, é a metodo mais atual de se liberar espaço fisico após grandes deleções de registros. Uma boa opção seria um upgrade do seu SGDB, assim você vai ter sempre os metodos mais atuais. Abraços, Em 30 de novembro de 2012 22:44, Fabrízio de Royes Mello fabriziome...@gmail.com escreveu: Em 30 de novembro de 2012 19:34, Euler Taveira eu...@timbira.comescreveu: [...] Desaconselho o uso do VF em favor do autovacuum + VACUUM manual (se necessário). Nem a nova implementação do VF é recomendada, claro que se tiver *janela de manutenção* para tal atividade ??? Att, -- Fabrízio de Royes Mello Consultoria/Coaching PostgreSQL Blog sobre TI: http://fabriziomello.blogspot.com Perfil Linkedin: http://br.linkedin.com/in/fabriziomello Twitter: http://twitter.com/fabriziomello ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral -- Targino Silveira +55-85-8626-7297 www.twitter.com/targinosilveira ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
[pgbr-geral] pgpool-II usando todos os cores em 100%
Boa noite pessoal, Esto usando pgpool-II para balancear a carga entre um PG-Master e um PG-Slave, porém depois de alguns minutos o pgpool passa a usar 100% de todos os cores e elevar bastante o load average da máquina, a mesma tem bastante memória mais os processo do pgpool não estão alocando muita memória. Alguém já passou por algo semelhante ? Abraços, -- Targino Silveira +55-85-8626-7297 www.twitter.com/targinosilveira ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
