Re: [pgbr-geral] Vacuum e Vacuum Full

2017-09-25 Por tôpico Fernando Franquini 'capin'
Em 22 de setembro de 2017 22:20, Euler Taveira escreveu: > Em 22 de setembro de 2017 16:36, Fernando Franquini 'capin' < > fernando.franqu...@gmail.com> escreveu: > >> >> tenho um ambiente com Postgres 9.3.19. >> Linux Centos 6 Kernel 2.6.32-504.12.2.el6.x86_64 (sei que é

Re: [pgbr-geral] Vacuum e Vacuum Full

2017-09-22 Por tôpico Euler Taveira
Em 22 de setembro de 2017 16:36, Fernando Franquini 'capin' < fernando.franqu...@gmail.com> escreveu: > > tenho um ambiente com Postgres 9.3.19. > Linux Centos 6 Kernel 2.6.32-504.12.2.el6.x86_64 (sei que é velho! eheh) > > Se ambos estiverem com correções aplicadas, não vejo problema (pelo menos

Re: [pgbr-geral] Vacuum e Vacuum Full

2017-09-22 Por tôpico Daniel Luiz da Silva
De: "Fernando Franquini 'capin'" <fernando.franqu...@gmail.com> Para: "Lista: Comunidade PostgreSQL Brasileira" <pgbr-geral@listas.postgresql.org.br> Enviadas: Sexta-feira, 22 de setembro de 2017 16:36:46 Assunto: [pgbr-geral] Vacuum e Vacuum Full B

[pgbr-geral] Vacuum e Vacuum Full

2017-09-22 Por tôpico Fernando Franquini 'capin'
Boa tarde, tenho um ambiente com Postgres 9.3.19. Linux Centos 6 Kernel 2.6.32-504.12.2.el6.x86_64 (sei que é velho! eheh) Tenho várias tabelas que são removidos e inseridos vários dados durante o dia todo, tempo todo. Preciso as vezes executar vacuum e vacuum full na mão, vou colocar um print

Re: [pgbr-geral] Vacuum e autovacuum

2017-09-04 Por tôpico Euler Taveira
Em 4 de setembro de 2017 09:51, Luiz Carlos L. Nogueira Jr. escreveu: > E o que fazer para evitar que o autovacuum rode durante o expediente? > Antes de mais nada, por que desabilitar o autovacuum durante o expediente? "porque ele trava a tabela" ou "porque ele prejudica a

Re: [pgbr-geral] Vacuum e autovacuum

2017-09-04 Por tôpico Luiz Carlos L. Nogueira Jr.
Fabio/Euler, E o que fazer para evitar que o autovacuum rode durante o expediente? Não entendo uma coisa. Se eu passo o vacuum manual achava que ele dizia "olhe não tem linhas a serem recicladas", mas isso não acontece pois o autovacuum não considera isso

Re: [pgbr-geral] Vacuum e autovacuum

2017-08-30 Por tôpico Euler Taveira
Em 30 de agosto de 2017 17:54, Luiz Carlos L. Nogueira Jr. escreveu: > Hoje o autovacuum apareceu de novo e fui olhar as estatísticas da tabela e > tinha: > last autovacuum: 23/08/2017 ... > last vacuum: 29/08/2017 ... > > Eu imaginei que dando o vacuum ele "zeraria" as

Re: [pgbr-geral] Vacuum e autovacuum

2017-08-30 Por tôpico Fábio Telles Rodriguez
Em 30 de agosto de 2017 17:54, Luiz Carlos L. Nogueira Jr. < lcnogueir...@gmail.com> escreveu: > Pessoal, > > Estava notando uma coisa em relação ao vacuum e autovacuum. > Como estava ocorrendo muito autovacuum no horário de expediente numa certa > tabela, coloquei pra ser feito um vacuum todo

[pgbr-geral] Vacuum e autovacuum

2017-08-30 Por tôpico Luiz Carlos L. Nogueira Jr.
Pessoal, Estava notando uma coisa em relação ao vacuum e autovacuum. Como estava ocorrendo muito autovacuum no horário de expediente numa certa tabela, coloquei pra ser feito um vacuum todo dia fora do expediente. Hoje o autovacuum apareceu de novo e fui olhar as estatísticas da tabela e tinha:

Re: [pgbr-geral] VACUUM FULL

2017-01-27 Por tôpico Euler Taveira
On 27-01-2017 14:51, Danilo Silva wrote: > ​OK, achei no histórico [1] um tópico onde fala que podemos nos basear > pela view pg_stat_all_tables (coluna n_dead_tup) para verificar a > eficiência do autovacuum, mas em relação a coluna n_dead_tup, qual > número seria relevante, fazer valer a pena,

Re: [pgbr-geral] VACUUM FULL

2017-01-27 Por tôpico Leandro Guimaraens Faria Corcete DUTRA
Le ven. 27 janv. 2017 à 15:51, Danilo Silva a écrit : Pergunto isso pois estou com problemas de espaço em disco, então estamos tentando tirar cada Mb de onde der pra tirar, mas não queremos comprometer a eficiência do banco. Problemas de espaço em disco são

Re: [pgbr-geral] VACUUM FULL

2017-01-27 Por tôpico Danilo Silva
Em 26 de janeiro de 2017 13:53, Fabrízio de Royes Mello < fabri...@timbira.com.br> escreveu: > On 26-01-2017 12:19, Danilo Silva wrote: > > Pessoal, > > > > Atualmente utilizo a versão 9.3 com replicação nativa para um escravo, > > fazendo cópia dos archives para o escravo + servidor de backup. >

Re: [pgbr-geral] VACUUM FULL

2017-01-26 Por tôpico Fabrízio de Royes Mello
On 26-01-2017 12:19, Danilo Silva wrote: > Pessoal, > > Atualmente utilizo a versão 9.3 com replicação nativa para um escravo, > fazendo cópia dos archives para o escravo + servidor de backup. > > Como podemos identificar a necessidade ou não de rodar um VACUUM FULL? > Se vc der uma pesquisada

[pgbr-geral] VACUUM FULL

2017-01-26 Por tôpico Danilo Silva
Pessoal, Atualmente utilizo a versão 9.3 com replicação nativa para um escravo, fazendo cópia dos archives para o escravo + servidor de backup. Como podemos identificar a necessidade ou não de rodar um VACUUM FULL? Como teste, rodei o VACUUM FULL apenas em uma tabela de 700mb e o diretório

Re: [pgbr-geral] vacuum analyze por tabela

2016-09-16 Por tôpico Guimarães Faria Corcete DUTRA , Leandro
2016-09-16 19:15 GMT-03:00 Luiz Henrique : > > Quando saber que preciso executar vacuum analyze individual por tabela ? Não precisa, deixe o autovácuo trabalhar. > Que parâmetros / estatísticas procurar para indicar que a tabela merece um > vacuum ? > Alguem tem /

[pgbr-geral] vacuum analyze por tabela

2016-09-16 Por tôpico Luiz Henrique
Pessoal, Quando saber que preciso executar vacuum analyze individual por tabela ? Que parâmetros / estatísticas procurar para indicar que a tabela merece um vacuum ? Alguem tem / recomenda um select que lista isso ? Obrigado! ___ pgbr-geral mailing list

Re: [pgbr-geral] VACUUM FULL ANALYZE VERBOSE

2016-04-14 Por tôpico Luiz Carlos L. Nogueira Jr.
Versão atualizada pra 9.3.12. O problema aparentemente foi corrigido. Fiz os mesmos testes . [QUERY] VACUUM FULL analyze verbose jbpm_byteblock INFO: vacuuming "public.jbpm_byteblock" INFO: "jbpm_byteblock": found 8994 removable, 18829714 nonremovable row versions

Re: [pgbr-geral] VACUUM FULL ANALYZE VERBOSE

2016-04-06 Por tôpico Luiz Carlos L. Nogueira Jr.
Flavio, É uma questão que não depende só de mim, mas vou tentar. ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] VACUUM FULL ANALYZE VERBOSE

2016-04-06 Por tôpico Flavio Henrique Araque Gurgel
Rafael, Iremos fazer isso em breve. Atualizar pra 9.3.12 é um processo simples, basta atualizar os binários e reiniciar o banco. É a única sugestão que você não seguiu e não entendemos o porquê. Você não precisa ir "direto pra 9.5.2", entendo que você precisa corrigir o seu problema na

Re: [pgbr-geral] VACUUM FULL ANALYZE VERBOSE

2016-04-06 Por tôpico Luiz Carlos L. Nogueira Jr.
Rafael, Iremos fazer isso em breve. ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] VACUUM FULL ANALYZE VERBOSE

2016-04-06 Por tôpico Rafael Fialho
Em 6 de abril de 2016 09:01, Luiz Carlos L. Nogueira Jr. < lcnogueir...@gmail.com> escreveu: > > Se tiverem interesse de replicar o problema > > Tenham uma tabela grande (uns 30GB com blobs) > façam um > begin; > muitos deletes (50% da base) > commit; > Vacuum full analyse verbose > > Mesmo

Re: [pgbr-geral] VACUUM FULL ANALYZE VERBOSE

2016-04-06 Por tôpico Luiz Carlos L. Nogueira Jr.
Flávio, Não estava ocorrendo backup na hora, inclusive o banco nem está no modo archivelog. Ele é um banco que copiamos todo dia de produção pro ambiente de homologação. Euler, Sim, mas não tinha nenhuma presa, inclusive nenhuma aplicação usa esse banco. Ele só fica como template se pedirem pra

Re: [pgbr-geral] VACUUM FULL ANALYZE VERBOSE

2016-04-05 Por tôpico Euler Taveira
On 05-04-2016 08:23, Luiz Carlos L. Nogueira Jr. wrote: > max_prepared_transactions | 2000 > Você utiliza transações preparadas? > Apesar de ter resolvido o problema dando uma porrada de checkpoints, não > acho que esse seja um comportamento "normal" para o banco > Checkpoint não tem

Re: [pgbr-geral] VACUUM FULL ANALYZE VERBOSE

2016-04-05 Por tôpico Flavio Henrique Araque Gurgel
Euler, Sem replicação. E backup na hora do vacuum? (...) server_version | 9.3.4 Você ainda não atualizou. Lembra que eu disse que um bug relativo ao seu problema está corrigido? Apesar de ter resolvido o problema dando uma porrada de checkpoints, não acho que esse

Re: [pgbr-geral] VACUUM FULL ANALYZE VERBOSE

2016-04-05 Por tôpico Luiz Carlos L. Nogueira Jr.
Euler, Sem replicação. name | current_setting |source| sourcefile | sourceline

Re: [pgbr-geral] VACUUM FULL ANALYZE VERBOSE

2016-04-04 Por tôpico Euler Taveira
On 04-04-2016 09:26, Luiz Carlos L. Nogueira Jr. wrote: > Não entendo o motivo desse comportamento. > Você não apresentou o cenário do seu ambiente. Você possui replicação? Quais os parâmetros diferente do padrão [1] da sua configuração? [1]

Re: [pgbr-geral] VACUUM FULL ANALYZE VERBOSE

2016-04-04 Por tôpico Luiz Carlos L. Nogueira Jr.
Só consegui fazer o vacuum full depois de dar uma porrada de chekpoints na base. Mas com um checkpoint só não funcionou. Não entendo o motivo desse comportamento. ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br

Re: [pgbr-geral] VACUUM FULL ANALYZE VERBOSE

2016-04-01 Por tôpico Flavio Henrique Araque Gurgel
select version(); PostgreSQL 9.3.4 on x86_64-unknown-linux-gnu, compiled by gcc (GCC) 4.4.7 20120313 (Red Hat 4.4.7-4), 64-bit 9.3.4 -> 9.3.12 O release notes que te mandei já é da 9.3.6, você está bemm atrasado. Atualiza e depois nos diz se seu problema foi resolvido. Senão talvez

Re: [pgbr-geral] VACUUM FULL ANALYZE VERBOSE

2016-04-01 Por tôpico Luiz Carlos L. Nogueira Jr.
Completando WITH list(file) AS (SELECT * FROM pg_ls_dir('pg_multixact/offsets')) SELECT EXISTS (SELECT * FROM list WHERE file = '') AND NOT EXISTS (SELECT * FROM list WHERE file = '0001') AND NOT EXISTS (SELECT * FROM list WHERE file = '') AND EXISTS (SELECT * FROM

Re: [pgbr-geral] VACUUM FULL ANALYZE VERBOSE

2016-04-01 Por tôpico Luiz Carlos L. Nogueira Jr.
Flávio, select version(); PostgreSQL 9.3.4 on x86_64-unknown-linux-gnu, compiled by gcc (GCC) 4.4.7 20120313 (Red Hat 4.4.7-4), 64-bit select * from pg_prepared_xacts Sem linhas afetadas ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br

Re: [pgbr-geral] VACUUM FULL ANALYZE VERBOSE

2016-04-01 Por tôpico Flavio Henrique Araque Gurgel
Em qui, 31 de mar de 2016 22:28, Luiz Carlos L. Nogueira Jr. < lcnogueir...@gmail.com> escreveu: > versão 9.3 > > Nesse contexto isso não é relavante. > > --É relevante porque eu garanto que não estão sendo incluídas nem apagadas > as linhas. (pra naõ termos distorções nos valores) > > Durante a

Re: [pgbr-geral] VACUUM FULL ANALYZE VERBOSE

2016-03-31 Por tôpico Luiz Carlos L. Nogueira Jr.
versão 9.3 Nesse contexto isso não é relavante. --É relevante porque eu garanto que não estão sendo incluídas nem apagadas as linhas. (pra naõ termos distorções nos valores) Durante a execução do ANALYZE o processo é feito por amostragem, limitadas em até 30.000 linhas. Dessas linhas, ele

Re: [pgbr-geral] VACUUM FULL ANALYZE VERBOSE

2016-03-31 Por tôpico Sebastian Webber
2016-03-31 16:10 GMT-03:00 Luiz Carlos L. Nogueira Jr. < lcnogueir...@gmail.com>: > [QUERY] VACUUM FULL ANALYZE VERBOSE jbpm_byteblock > INFO: vacuuming "public.jbpm_byteblock" > INFO: "jbpm_byteblock": found 15505882 removable, 18439352 > nonremovable row versions

[pgbr-geral] VACUUM FULL ANALYZE VERBOSE

2016-03-31 Por tôpico Luiz Carlos L. Nogueira Jr.
[QUERY] VACUUM FULL ANALYZE VERBOSE jbpm_byteblock INFO: vacuuming "public.jbpm_byteblock" INFO: "jbpm_byteblock": found 15505882 removable, 18439352 nonremovable row versions in 4762603 pages DETAIL: 0 dead row versions cannot be removed yet.

Re: [pgbr-geral] Vacuum Full não remove dead rows

2015-11-27 Por tôpico Euler Taveira
On 24-11-2015 10:21, Bruno Silva wrote: > Estou executando um vacuum full que me retorna 121000 dead rows em uma > tabela que tem 1275820 registros. > Porém o Vacuum Full sempre alega que não pode removê-las ainda. > O que pode ocasionar isso? > Isso me parece transação (preparada) em execução a

Re: [pgbr-geral] Vacuum Full não remove dead rows

2015-11-27 Por tôpico Bruno Silva
Em 24 de novembro de 2015 15:53, JotaComm escreveu: > > Em 24 de novembro de 2015 11:21, Bruno Silva > escreveu: > >> Estou executando um vacuum full que me retorna 121000 dead rows em uma >> tabela que tem 1275820 registros. >> Porém o Vacuum Full

Re: [pgbr-geral] Vacuum Full não remove dead rows

2015-11-24 Por tôpico JotaComm
Opa! Em 24 de novembro de 2015 11:21, Bruno Silva escreveu: > Estou executando um vacuum full que me retorna 121000 dead rows em uma > tabela que tem 1275820 registros. > Porém o Vacuum Full sempre alega que não pode removê-las ainda. > O que pode ocasionar isso? > ​Qual

[pgbr-geral] Vacuum Full não remove dead rows

2015-11-24 Por tôpico Bruno Silva
Estou executando um vacuum full que me retorna 121000 dead rows em uma tabela que tem 1275820 registros. Porém o Vacuum Full sempre alega que não pode removê-las ainda. O que pode ocasionar isso? PostgreSQL 9.3.10 on x86_64-unknown-linux-gnu, compiled by gcc (GCC) 4.4.7 20120 313 (Red Hat

Re: [pgbr-geral] Vacuum e Vacuum Full

2015-06-19 Por tôpico Guimarães Faria Corcete DUTRA , Leandro
Em 19 de junho de 2015 09:46, Franklin Anderson de Oliveira Souza frankli...@gmail.com escreveu: Olá @Guimarães, estou usando a versão 9.3 rodando numa maquina CentOS. Executo via script shell agendado no crontab manutenções diárias de vacuum e analyse e somente finais de semana faço um vacuum

Re: [pgbr-geral] Vacuum e Vacuum Full

2015-06-19 Por tôpico Guimarães Faria Corcete DUTRA , Leandro
Em 19 de junho de 2015 09:37, Franklin Anderson de Oliveira Souza frankli...@gmail.com escreveu: A um tempo parei de realizar vacuum full no banco que tem aproximadamente 50 gigas devido a falta de espaço. Depois disso tenho reparado que o simples vacuum tem demorado cada vez mais. Isso é

[pgbr-geral] Vacuum e Vacuum Full

2015-06-19 Por tôpico Franklin Anderson de Oliveira Souza
Ola todos !! A um tempo parei de realizar vacuum full no banco que tem aproximadamente 50 gigas devido a falta de espaço. Depois disso tenho reparado que o simples vacuum tem demorado cada vez mais. Isso é previsivel ?! A falta de um vacuum mais completo pode demorar cada vez mais o tempo para

Re: [pgbr-geral] Vacuum full não reduz espaço/linhas removidas

2015-03-03 Por tôpico Matheus de Oliveira
2015-03-02 21:38 GMT-03:00 Fábio Gibon gi...@comexsystem.com.br: tenho uma tabela com 184MB, porém consultando o inchaço dela me mostra que a mesma deveria ter menos de 7MB. Nas estatísticas atualizadas mostra 6300 n_live_tup e 168000 n_dead_tup. Fiz um create table as select

Re: [pgbr-geral] Vacuum full não reduz espaço/linhas removidas

2015-03-03 Por tôpico Fabrízio de Royes Mello
On 02-03-2015 21:38, Fábio Gibon wrote: Pessoal, tenho uma tabela com 184MB, porém consultando o inchaço dela me mostra que a mesma deveria ter menos de 7MB. Nas estatísticas atualizadas mostra 6300 n_live_tup e 168000 n_dead_tup. Fiz um create table as select e a nova

Re: [pgbr-geral] Vacuum full não reduz espaço/linhas removidas

2015-03-02 Por tôpico Sebastian Webber
Em 2 de março de 2015 21:38, Fábio Gibon gi...@comexsystem.com.br escreveu: Pessoal, tenho uma tabela com 184MB, porém consultando o inchaço dela me mostra que a mesma deveria ter menos de 7MB. Nas estatísticas atualizadas mostra 6300 n_live_tup e 168000 n_dead_tup. Fiz

[pgbr-geral] Vacuum full não reduz espaço/linhas removidas

2015-03-02 Por tôpico Fábio Gibon
Pessoal, tenho uma tabela com 184MB, porém consultando o inchaço dela me mostra que a mesma deveria ter menos de 7MB. Nas estatísticas atualizadas mostra 6300 n_live_tup e 168000 n_dead_tup. Fiz um create table as select e a nova tabela ficou com 7MB (e com 6300 linhas,

Re: [pgbr-geral] Vacuum com outro comando

2014-03-11 Por tôpico Luiz Carlos L. Nogueira Jr.
Coloquei o statement_timeout pro usuário. ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Vacuum com outro comando

2014-03-06 Por tôpico Luiz Carlos L. Nogueira Jr.
Não deu certo echo SET statement_timeout TO 0; VACUUM table1; REINDEX TABLE table1; | psql postgres Mas já resolvi o problema. Obrigado a todos. E o Top posted foi mal, é que o gmail faz automático e eu esqueço de apagar ___ pgbr-geral mailing list

Re: [pgbr-geral] Vacuum com outro comando

2014-03-06 Por tôpico Guimarães Faria Corcete DUTRA , Leandro
2014-03-06 11:36 GMT-03:00 Luiz Carlos L. Nogueira Jr. lcnogueir...@gmail.com: Não deu certo echo SET statement_timeout TO 0; VACUUM table1; REINDEX TABLE table1; | psql postgres Mas já resolvi o problema. Como resolveu? -- skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra

Re: [pgbr-geral] Vacuum com outro comando

2014-02-26 Por tôpico Luiz Carlos L. Nogueira Jr.
Eu queria usar o set statement_timeout=0 junto coim o vacumm e o reindex. Mas, pra agilizar coloquei essa opção no login postgres e agora só rodo o vacuum no comando Em 24 de fevereiro de 2014 12:12, Flavio Henrique Araque Gurgel fha...@gmail.com escreveu: Em 24-02-2014 15:57, Luiz Carlos L.

Re: [pgbr-geral] Vacuum com outro comando

2014-02-26 Por tôpico Matheus de Oliveira
2014-02-26 8:09 GMT-03:00 Luiz Carlos L. Nogueira Jr. lcnogueir...@gmail.com: Eu queria usar o set statement_timeout=0 junto coim o vacumm e o reindex. Mas, pra agilizar coloquei essa opção no login postgres e agora só rodo o vacuum no comando Primeiro. Pare com o top-posting. Segundo,

Re: [pgbr-geral] Vacuum com outro comando

2014-02-26 Por tôpico Flavio Henrique Araque Gurgel
Eu queria usar o set statement_timeout=0 junto coim o vacumm e o reindex. Mas, pra agilizar coloquei essa opção no login postgres e agora só rodo o vacuum no comando Primeiro. Pare com o top-posting. Segundo, faça como o Fabrízio comentou: echo SET statement_timeout TO 0;

Re: [pgbr-geral] Vacuum com outro comando

2014-02-24 Por tôpico Luiz Carlos L. Nogueira Jr.
Dá erro pq o vacuum só pode ser o único comando a ser rodado. VACUUM cannot be executed from a function or multi-command string Em 14 de fevereiro de 2014 16:01, Fabrízio de Royes Mello fabri...@timbira.com.br escreveu: On 14-02-2014 16:52, Luiz Carlos L. Nogueira Jr. wrote: Pessoal,

Re: [pgbr-geral] Vacuum com outro comando

2014-02-24 Por tôpico Flavio Henrique Araque Gurgel
Em 24-02-2014 15:57, Luiz Carlos L. Nogueira Jr. escreveu: Dá erro pq o vacuum só pode ser o único comando a ser rodado. VACUUM cannot be executed from a function or multi-command string Então evite o top-posting. Você não pode fazer em comandos separados? psql postgres -c VACUUM table1

[pgbr-geral] Vacuum com outro comando

2014-02-14 Por tôpico Luiz Carlos L. Nogueira Jr.
Pessoal, Quando rodo psql postgres -c VACUUM table1; REINDEX table1 Dá esse erro: ERROR: VACUUM cannot be executed from a function or multi-command string Tem alguma coisa que possa fazer pra executar um comando e depois o outro. Sem mais, Luiz Carlos

Re: [pgbr-geral] Vacuum com outro comando

2014-02-14 Por tôpico Luiz Carlos L. Nogueira Jr.
Esquece, é só colocar um chr(10) entre os comandos 2014-02-14 15:52 GMT-03:00 Luiz Carlos L. Nogueira Jr. lcnogueir...@gmail.com: Pessoal, Quando rodo psql postgres -c VACUUM table1; REINDEX table1 Dá esse erro: ERROR: VACUUM cannot be executed from a function or multi-command string

Re: [pgbr-geral] Vacuum com outro comando

2014-02-14 Por tôpico Fabrízio de Royes Mello
On 14-02-2014 16:52, Luiz Carlos L. Nogueira Jr. wrote: Pessoal, Quando rodo psql postgres -c VACUUM table1; REINDEX table1 Dá esse erro: ERROR: VACUUM cannot be executed from a function or multi-command string Tem alguma coisa que possa fazer pra executar um comando e depois o outro.

Re: [pgbr-geral] VACUUM FREEZE - Tuplas Congeladas

2013-12-16 Por tôpico Mariana Hansen
Em 13 de dezembro de 2013 15:17, Flavio Henrique Araque Gurgel fha...@gmail.com escreveu: Deixe-me ver se entendi. O congelamento evita que os XIDs sejam mudados ao início de um novo ciclo de numeração de XIDs, pq caso contrário teriam um XID inferior a transações mais antigas? Simples

[pgbr-geral] VACUUM FREEZE - Tuplas Congeladas

2013-12-13 Por tôpico Mariana Hansen
Boa tarde, pessoal. Alguém por gentileza poderia me explicar o que é o congelamento de tuplas e para que serve. Obrigada. ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br

Re: [pgbr-geral] VACUUM FREEZE - Tuplas Congeladas

2013-12-13 Por tôpico Flavio Henrique Araque Gurgel
Alguém por gentileza poderia me explicar o que é o congelamento de tuplas e para que serve. É a troca dos identificadores de transação sobre todas as tuplas da tabela, para entrarem no intervalo superior à transação mais antiga possível nela. Isso é feito pra que, quando o contador de

Re: [pgbr-geral] VACUUM FREEZE - Tuplas Congeladas

2013-12-13 Por tôpico Mariana Hansen
Em 13 de dezembro de 2013 15:00, Flavio Henrique Araque Gurgel fha...@gmail.com escreveu: Alguém por gentileza poderia me explicar o que é o congelamento de tuplas e para que serve. É a troca dos identificadores de transação sobre todas as tuplas da tabela, para entrarem no intervalo

Re: [pgbr-geral] VACUUM FREEZE - Tuplas Congeladas

2013-12-13 Por tôpico Flavio Henrique Araque Gurgel
Deixe-me ver se entendi. O congelamento evita que os XIDs sejam mudados ao início de um novo ciclo de numeração de XIDs, pq caso contrário teriam um XID inferior a transações mais antigas? Simples assim? :) Na verdade é bem o contrário. A opção FREEZE vai fazer com que a idade mínima da tabela

[pgbr-geral] VACUUM e/ou CLUSTER

2013-09-05 Por tôpico Nelson L. Gonzaga
Ola a todos, Tenho um banco de aprox 50Gb que somente é utilizado no horário comercial. Toda noite é executado um script com os comandos(nesta ordem): 1) VACUUM FULL FREEZE VERBOSE ANALYZE 2) PG_DUMP 3) CLUSTER Minha duvida é: Estou exagerando de alguma forma? Eu sei que Vacuum

Re: [pgbr-geral] VACUUM e/ou CLUSTER

2013-09-05 Por tôpico Guimarães Faria Corcete DUTRA , Leandro
2013/9/5 Nelson L. Gonzaga nelson.gonz...@toshiba.com.br: Tenho um banco de aprox 50Gb que somente é utilizado no horário comercial. Toda noite é executado um script com os comandos(nesta ordem): 1) VACUUM FULL FREEZE VERBOSE ANALYZE 2) PG_DUMP 3) CLUSTER Estou exagerando de

Re: [pgbr-geral] VACUUM e/ou CLUSTER

2013-09-05 Por tôpico Glauco Torres
Tenho um banco de aprox 50Gb que somente é utilizado no horário comercial. Toda noite é executado um script com os comandos(nesta ordem): ** ** **1) **VACUUM FULL FREEZE VERBOSE ANALYZE **2) **PG_DUMP **3) **CLUSTER ** ** Minha duvida é:

Re: [pgbr-geral] VACUUM e/ou CLUSTER

2013-09-05 Por tôpico Euler Taveira
On 05-09-2013 11:41, Nelson L. Gonzaga wrote: Estou exagerando de alguma forma? Eu sei que Vacuum e cluster não são a mesma coisa, mas são complementares e no fim das contas dá no mesmo usar um ou outro? É um exagero! VACUUM FULL a partir da 9.0 é uma variante do CLUSTER; o VACUUM já é outra

Re: [pgbr-geral] Vacuum / Reindex / Dump Restore

2012-08-24 Por tôpico Fabrízio de Royes Mello
Em 23 de agosto de 2012 22:58, Flavio Henrique Araque Gurgel fla...@4linux.com.br escreveu: [...] Na versão 9.1 ou superior o VACUUM FULL funciona como CLUSTER sem porém ordenar a tabela por um índice. O CLUSTER, todavia, permanece disponível. Vc quis dizer 9.0 ou superiores né! Att, --

Re: [pgbr-geral] Vacuum / Reindex / Dump Restore

2012-08-24 Por tôpico Matheus de Oliveira
2012/8/23 Bruno Silva bemanuel...@gmail.com É Flávio, vontade não falta. Porém o sistema é grande e tenho mudado ele aos poucos - pessoalmente - para ser compatível com o 9.1, digamos que o desenvolvimento do sistema foi feito sem preocupação nenhuma com Casts ( fora outros absurdos ). Uma

Re: [pgbr-geral] Vacuum / Reindex / Dump Restore

2012-08-24 Por tôpico Bruno Silva
Opa Matheus, Quanto aos casts estou sim fazendo aos poucos, por isso o processo é lento. Mas vou olhar o link que você me mandou. Só a possibilidade de uso do hot-standby já resolveria 20% dos problemas na parte do BI. O Vacuum Full vi mesmo falando sobre a degradação - a madrugada foi proveitosa.

Re: [pgbr-geral] Vacuum / Reindex / Dump Restore

2012-08-24 Por tôpico Matheus de Oliveira
2012/8/24 Bruno Silva bemanuel...@gmail.com Opa Matheus, Quanto aos casts estou sim fazendo aos poucos, por isso o processo é lento. Mas vou olhar o link que você me mandou. Só a possibilidade de uso do hot-standby já resolveria 20% dos problemas na parte do BI. Pra BI você pode

Re: [pgbr-geral] Vacuum / Reindex / Dump Restore

2012-08-24 Por tôpico Flavio Henrique Araque Gurgel
Em 23-08-2012 23:40, Bruno Silva escreveu: É Flávio, vontade não falta. Porém o sistema é grande e tenho mudado ele aos poucos - pessoalmente - para ser compatível com o 9.1, digamos que o desenvolvimento do sistema foi feito sem preocupação nenhuma com Casts ( fora outros absurdos ). Então

Re: [pgbr-geral] Vacuum / Reindex / Dump Restore

2012-08-24 Por tôpico Flavio Henrique Araque Gurgel
Em 24-08-2012 08:19, Fabrízio de Royes Mello escreveu: Em 23 de agosto de 2012 22:58, Flavio Henrique Araque Gurgel fla...@4linux.com.br mailto:fla...@4linux.com.br escreveu: [...] Na versão 9.1 ou superior o VACUUM FULL funciona como CLUSTER sem porém ordenar a tabela por um

Re: [pgbr-geral] Vacuum / Reindex / Dump Restore

2012-08-24 Por tôpico Euler Taveira
On 24-08-2012 16:33, Flavio Henrique Araque Gurgel wrote: Em 24-08-2012 08:19, Fabrízio de Royes Mello escreveu: Em 23 de agosto de 2012 22:58, Flavio Henrique Araque Gurgel fla...@4linux.com.br mailto:fla...@4linux.com.br escreveu: [...] Na versão 9.1 ou superior o VACUUM FULL

Re: [pgbr-geral] Vacuum / Reindex / Dump Restore

2012-08-24 Por tôpico Flavio Henrique Araque Gurgel
Em 24-08-2012 16:36, Euler Taveira escreveu: Vc quis dizer 9.0 ou superiores né! 9.1 ou superiores mesmo, quando o código do VACUUM FULL foi otimizado, gerando uma tabela nova e apagando a antiga no final, o que é mais rápido mas precisa de espaço pra nova tabela no disco. O Fabrizio está

[pgbr-geral] Vacuum / Reindex / Dump Restore

2012-08-23 Por tôpico Bruno Silva
Boa tarde, estou analisando e estudando algumas coisas referentes a performance e tamanho das bases de dados e me surgiu uma dúvida. O Dump e Restore continua sendo a melhor alternativa em detrimento do Reindex e Vacuum ? http://www.linuxinsight.com/optimize_postgresql_database_size.html Bruno E.

Re: [pgbr-geral] Vacuum / Reindex / Dump Restore

2012-08-23 Por tôpico Flávio Alves Granato
Em 23/08/2012 15:00, Bruno Silva escreveu: Boa tarde, estou analisando e estudando algumas coisas referentes a performance e tamanho das bases de dados e me surgiu uma dúvida. O Dump e Restore continua sendo a melhor alternativa em detrimento do Reindex e Vacuum ?

Re: [pgbr-geral] Vacuum / Reindex / Dump Restore

2012-08-23 Por tôpico Bruno Silva
Eu também, acho, por isso questionei. E como tenho ambientes com 9.1 e 8.2 fiquei na dúvida. De se e quando mudou. Bruno E. A. Silva. 2012/8/23 Flávio Alves Granato flavio.gran...@gmail.com Em 23/08/2012 15:00, Bruno Silva escreveu: Boa tarde, estou analisando e estudando algumas coisas

Re: [pgbr-geral] Vacuum / Reindex / Dump Restore

2012-08-23 Por tôpico Fabrízio de Royes Mello
Em 23 de agosto de 2012 15:08, Flávio Alves Granato flavio.gran...@gmail.com escreveu: Em 23/08/2012 15:00, Bruno Silva escreveu: Boa tarde, estou analisando e estudando algumas coisas referentes a performance e tamanho das bases de dados e me surgiu uma dúvida. O Dump e Restore continua

Re: [pgbr-geral] Vacuum / Reindex / Dump Restore

2012-08-23 Por tôpico Flavio Henrique Araque Gurgel
On 23-08-2012 22:24, Bruno Silva wrote: E no caso de um vacuum full em uma base 8.2 vocês indicam alguns parâmetros para melhorar a performance durante o mesmo? A melhor recomendação: atualize sua versão. 8.2 não é mais suportado. Em versões 9.0 ou anteriores do PostgreSQL, substitua VACUUM

Re: [pgbr-geral] Vacuum / Reindex / Dump Restore

2012-08-23 Por tôpico Bruno Silva
É Flávio, vontade não falta. Porém o sistema é grande e tenho mudado ele aos poucos - pessoalmente - para ser compatível com o 9.1, digamos que o desenvolvimento do sistema foi feito sem preocupação nenhuma com Casts ( fora outros absurdos ). Então estou com essa preocupação diária. Estava lendo

Re: [pgbr-geral] Vacuum full - informação de execução

2011-11-08 Por tôpico Leonardo Carneiro
2011/11/8 Euler Taveira de Oliveira eu...@timbira.com On 07-11-2011 19:55, Fábio Gibon - Comex System wrote: o vacuum com a opção de full não fica registrado na pg_stat_all_tables (em last_vacuum). Há algum local do dicionário de dados que eu encontro a data do último vacuum full de uma

Re: [pgbr-geral] Vacuum full - informação de execução

2011-11-08 Por tôpico Euler Taveira de Oliveira
On 08-11-2011 07:51, Leonardo Carneiro wrote: Interessante essa info sobre o vacuum full. Algumas pessoas comentaram durante o pgbr que o vacuum full não deveria ser usado antes da versão 9 sem executar reindex, pois iria ser prejudicial aos índices. Eu não o recomendado desde 7.4. A

[pgbr-geral] Vacuum full - informação de execução

2011-11-07 Por tôpico Fábio Gibon - Comex System
Pessoal, o vacuum com a opção de full não fica registrado na pg_stat_all_tables (em last_vacuum). Há algum local do dicionário de dados que eu encontro a data do último vacuum full de uma tabela? abraços Fábio Henrique Gibon___ pgbr-geral

Re: [pgbr-geral] Vacuum full - informação de execução

2011-11-07 Por tôpico Fábio Gibon - Comex System
Complementando... versão 9.0.3 - Original Message - From: Fábio Gibon - Comex System To: PostgreSQL - BR List Sent: Monday, November 07, 2011 7:55 PM Subject: [pgbr-geral] Vacuum full - informação de execução Pessoal, o vacuum com a opção de full não fica

Re: [pgbr-geral] Vacuum full - informação de execução

2011-11-07 Por tôpico JotaComm
@listas.postgresql.org.br *Sent:* Monday, November 07, 2011 7:55 PM *Subject:* [pgbr-geral] Vacuum full - informação de execução Pessoal, o vacuum com a opção de full não fica registrado na pg_stat_all_tables (em last_vacuum). Há algum local do dicionário de dados que eu encontro a data do último vacuum

Re: [pgbr-geral] Vacuum full - informação de execução

2011-11-07 Por tôpico Fábio Gibon - Comex System
bases que testei? um abraço Gibon - Original Message - From: JotaComm To: Fábio Gibon - Comex System ; Comunidade PostgreSQL Brasileira Sent: Monday, November 07, 2011 8:59 PM Subject: Re: [pgbr-geral] Vacuum full - informação de execução Olá, Fábio Em 7 de novembro de

Re: [pgbr-geral] Vacuum full - informação de execução

2011-11-07 Por tôpico Euler Taveira de Oliveira
On 07-11-2011 19:55, Fábio Gibon - Comex System wrote: o vacuum com a opção de full não fica registrado na pg_stat_all_tables (em last_vacuum). Há algum local do dicionário de dados que eu encontro a data do último vacuum full de uma tabela? Isso é verdade a partir da versão 9.0 (quando o

Re: [pgbr-geral] Vacuum Full Silmutaneo é possíve l?

2010-10-07 Por tôpico jeffersondias
Quando rodo o Vacuum em todas as tabelas isso leva quase 24horas. Percebo que não é usado quase nada de Processamento do servidor e nem de memória. Consigo ou posso rodar vacuum simultaneamente (vacuumdb -f -v -z -d ) ao invez de hoje q faço um a um eu rodar varios vaccumdb simutaneos. Isso pode

Re: [pgbr-geral] Vacuum Full Silmutaneo é possível ?

2010-10-07 Por tôpico Jefferson Dias
core e 128Gb de memória o banco esta com 150Gb de uso hoje. Date: Wed, 6 Oct 2010 17:38:02 -0300 From: fabriziome...@gmail.com To: pgbr-geral@listas.postgresql.org.br Subject: Re: [pgbr-geral] Vacuum Full Silmutaneo é possível? ___ pgbr-geral

Re: [pgbr-geral] Vacuum Full Silmutaneo é possível ?

2010-10-07 Por tôpico Osvaldo Kussama
Em 6 de outubro de 2010 16:36, jeffersondias jefferso...@hotmail.com escreveu: Quando rodo o Vacuum em todas as tabelas isso leva quase 24horas. Percebo que não é usado quase nada de Processamento do servidor e nem de memória. Consigo ou posso rodar vacuum simultaneamente (vacuumdb -f -v -z

Re: [pgbr-geral] Vacuum Full Silmutaneo é possível ?

2010-10-07 Por tôpico Euler Taveira de Oliveira
Jefferson Dias escreveu: Uma vez por semana (domingo inteiro hoje) Sim eu rodo do catalogo mas rodo um a um e isso demora 22h . A maior tabela demora 8h ai dividiria em varios arquivos a fim de fazer todo esse vaccum em 8 horas ao invéz de 22h e colocaria eles no crontab do linux. Bem o

[pgbr-geral] Vacuum Full Silmutaneo é possíve l?

2010-10-06 Por tôpico jeffersondias
Quando rodo o Vacuum em todas as tabelas isso leva quase 24horas. Percebo que não é usado quase nada de Processamento do servidor e nem de memória. Consigo ou posso rodar vacuum simultaneamente (vacuumdb -f -v -z -d ) ao invez de hoje q faço um a um eu rodar varios vaccumdb simutaneos. Isso pode

Re: [pgbr-geral] Vacuum Full Silmutaneo é possível ?

2010-10-06 Por tôpico Fabrízio de Royes Mello
Em 6 de outubro de 2010 16:36, jeffersondias jefferso...@hotmail.comescreveu: Quando rodo o Vacuum em todas as tabelas isso leva quase 24horas. Percebo que não é usado quase nada de Processamento do servidor e nem de memória. Consigo ou posso rodar vacuum simultaneamente (vacuumdb -f -v -z

[pgbr-geral] Vacuum full e analyse

2010-08-27 Por tôpico marlon david de souza
Bom dia a todos, Tenho a seguinte dúvida: dento do processo do vaccum full já é feito o processo de analyse ou é necessário executar os dois processos separadamente? Sem mais, Marlon David de Souza Desenvolvedor ___ pgbr-geral mailing

Re: [pgbr-geral] Vacuum full e analyse

2010-08-27 Por tôpico JotaComm
Olá, Em 27 de agosto de 2010 11:37, marlon david de souza mar...@sysmo.com.brescreveu: Bom dia a todos, Tenho a seguinte dúvida: dento do processo do *vaccum full* já é feito o processo de *analyse* ou é necessário executar os dois processos separadamente? Depende. Se você

[pgbr-geral] Vacuum Warning

2010-06-14 Por tôpico mateusgra
WARNING: relation cad page is uninitialized --- fixing O que seria a menssagem acima ? -- View this message in context: http://old.nabble.com/Vacuum-Warning-tp28884050p28884050.html Sent from the PostgreSQL - Brasil mailing list archive at Nabble.com.

Re: [pgbr-geral] Vacuum Warning

2010-06-14 Por tôpico Euler Taveira de Oliveira
mateusgra escreveu: WARNING: relation cad page is uninitialized --- fixing O que seria a menssagem acima ? Provavelmente algum _backend_ que foi terminado inadequadamente, assim uma página da relação citada não foi inicializada corretamente. -- Euler Taveira de Oliveira

Re: [pgbr-geral] Vacuum Warning

2010-06-14 Por tôpico mateusgra
Mas a tabela esta corrompida? Euler Taveira de Oliveira-2 wrote: mateusgra escreveu: WARNING: relation cad page is uninitialized --- fixing O que seria a menssagem acima ? Provavelmente algum _backend_ que foi terminado inadequadamente, assim uma página da relação citada não foi

Re: [pgbr-geral] Vacuum Warning

2010-06-14 Por tôpico Euler Taveira de Oliveira
mateusgra escreveu: Mas a tabela esta corrompida? Não. Por isso que a mensagem é do tipo WARNING. -- Euler Taveira de Oliveira http://www.timbira.com/ ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br

[pgbr-geral] vacuum no cron com autenticacao de root

2009-07-01 Por tôpico jorge sanfelice
Prezados, Estou com o seguinte problema, tenho uma rotina de vacuum no cron, mas como é nessaria a autenticacao do usuario root, nao esta rodando: Ex: 00 02 * * * /usr/bin/vacuumdb -f -z -v -d banco /var/log/postgres/vacuum.log 21 Ai tive que fazer isso no pg_hba.conf para funcionar local all

[pgbr-geral] vacuum em 2 ou mais tabelas ao mesmo tempo

2009-05-08 Por tôpico jorge sanfelice
Pessoal, Alguem sabe se seria possivel executar vacuum em mais de uma tabela ao mesmo tempo (de um modo que nao precise escolher todas) ? Ex: Vacuum Analyze tabx,taby,tabz; Pergunto isso, porque em alguns momentos tenho que executar vaccum analyze ou vacuum full em 5,10, 20 etc... tabelas em

  1   2   >