Em 14 de novembro de 2016 18:06, Sebastian Webber
escreveu:
>
>
> Em 14 de novembro de 2016 16:01, Daniel Luiz da Silva <
> daniel.si...@ipm.com.br> escreveu:
>
>
>> Valeu Seba,
>>
>
> :)
>
>
>>
>> Ficou boa tradução, a ideia principal ficou acessível para compreensão.
>> Só não entendi a frase
Em 14 de novembro de 2016 16:01, Daniel Luiz da Silva <
daniel.si...@ipm.com.br> escreveu:
> Valeu Seba,
>
:)
>
> Ficou boa tradução, a ideia principal ficou acessível para compreensão.
> Só não entendi a frase "...A média de densidade da folha é a porcentagem
> do uso da página de índice de f
Em 14 de novembro de 2016 15:24, Flavio Henrique Araque Gurgel <
fha...@gmail.com> escreveu:
>
> Eu li rapidamente e não achei nada que desabonasse sua tradução :)
>
Valeu! :)
> Mas não entendi porque você insistiu em chamar de AutoVACUUM, no artigo
> original está bem bonitinho "Autovacuum",
De: "Flavio Henrique Araque Gurgel"
Para: "Comunidade PostgreSQL Brasileira"
Enviadas: Segunda-feira, 14 de novembro de 2016 15:24:17
Assunto: Re: [pgbr-geral] Autovacuum não é o inimigo! [Ajuda pra revisar
tradução]
Em seg, 14 de nov de 2016 às 17:46, Sebas
Em seg, 14 de nov de 2016 às 17:46, Sebastian Webber
escreveu:
> Pessoal,
>
> achei um artigo incrivel[1] no blog da citus data que fala do autovacuum.
> Entrei em contato com os caras e pedi autorização pra traduzir ele pra
> pt-br.
>
> Fiz a tradução e coloquei no meu blog[2].
>
> Alguma alma c
Pessoal,
achei um artigo incrivel[1] no blog da citus data que fala do autovacuum.
Entrei em contato com os caras e pedi autorização pra traduzir ele pra
pt-br.
Fiz a tradução e coloquei no meu blog[2].
Alguma alma caridosa poderia dar uma revisada e me ajudar a arrumar
qualquer erro de tradução
Muito obrigado Dickson!
Irei fazer a leitura e, posteriormente, posto os resultados.
Evite o top-posting por favor.
Note que, independente do tamanho de suas tabelas, se elas só tem INSERT
o autovacuum não fará vacuum, só analyze.
Você postou o comando que mostra isso mas, infelizmente, não p
Muito obrigado Dickson!
Irei fazer a leitura e, posteriormente, posto os resultados.
Obrigado!
2015-12-14 11:48 GMT+13:00 Dickson S. Guedes :
> On Mon, Dec 14, 2015 at 10:47:00AM +1300, drum.lu...@gmail.com wrote:
> > Ola a todos!
> >
> > Primeiramente, me apresentando:
> > Sou o Lucas, atualmen
On Mon, Dec 14, 2015 at 10:47:00AM +1300, drum.lu...@gmail.com wrote:
> Ola a todos!
>
> Primeiramente, me apresentando:
> Sou o Lucas, atualmente trabalho como DBA na Nova Zelandia (por isto a
> falta de acentos hhehehe).
Ola! Seja bem vindo! UTF-8 a parte, responderei sem acentos.
> [... cor
Ola a todos!
Primeiramente, me apresentando:
Sou o Lucas, atualmente trabalho como DBA na Nova Zelandia (por isto a
falta de acentos hhehehe).
Nao tenho experiencia com Postgres, mas tenho com MYSQL.
Hoje tenho um ambiente bem grande, com uma DB de cerca de 2 TB (1 master +
2 hot standby slaves)
Além da documentação padrão do Postgres, onde posso ler sobre
parametrização do autovacuum ?
Pretendo analisar algumas tabelas e quero evitar a necessidade de aplicação
do vacuum manual, ou através do crontab como vejo em alguns ambientes.
Bruno E. A. Silva.
___
Verifique em pg_stat_activity se o autovacuum é do tipo "to prevent
wraparound". Provavelmente é.
Você verificou isto? Não disse em sua resposta.
Se for, não há muito o que fazer, ele vai entrar. Você pode aumentar
o valor de autovacuum_freeze_max_age mas isso é paliativo e um
Em 19 de dezembro de 2013 09:16, Flavio Henrique Araque Gurgel <
fha...@gmail.com> escreveu:
> Pessoal,
>>
>> Estou tendo problemas com a minha aplicação onde sempre que se inicia o
>> autovacuum, a aplicação trava.
>>
>> Olhando na atividade dos processos do postgres, o autovacuum está em uma
>>
Pessoal,
Estou tendo problemas com a minha aplicação onde sempre que se inicia o
autovacuum, a aplicação trava.
Olhando na atividade dos processos do postgres, o autovacuum está em uma
tabela que contém 9 GiB e o banco inteiro está com 17 GiB, porém, essa
tabela contém campo bytea.
Para não dei
Pessoal,
Estou tendo problemas com a minha aplicação onde sempre que se inicia o
autovacuum, a aplicação trava.
Olhando na atividade dos processos do postgres, o autovacuum está em uma
tabela que contém 9 GiB e o banco inteiro está com 17 GiB, porém, essa
tabela contém campo bytea.
Para não deix
Em 21 de janeiro de 2013 13:53, Flavio Henrique Araque Gurgel <
fla...@4linux.com.br> escreveu:
>
> Em 21-01-2013 12:40, Danilo Silva escreveu:
> > Uai, então ocorreu o que você queria!
> > O processo autovacuum launcher não pode mais aparecer no seu top, ps,
> > etc... Ele continua lá
Em 21-01-2013 12:40, Danilo Silva escreveu:
> Uai, então ocorreu o que você queria!
> O processo autovacuum launcher não pode mais aparecer no seu top, ps,
> etc... Ele continua lá?
>
>
> Após o reload, eu aguardei alguns segundos, como não desapareceu, eu
> reiniciei o serviço.
Pelo
Em 21 de janeiro de 2013 12:25, Flavio Henrique Araque Gurgel <
fla...@4linux.com.br> escreveu:
> Em 21-01-2013 11:41, Danilo Silva escreveu:
> (...)
>
> > Qual procedimento executou para o reload?
> >
> > /etc/init.d/postgresql-9.1 reload
> >
> > O log do PostgreSQL acusou o reload?
> >
>
Em 21-01-2013 11:41, Danilo Silva escreveu:
(...)
> Qual procedimento executou para o reload?
>
> /etc/init.d/postgresql-9.1 reload
>
> O log do PostgreSQL acusou o reload?
>
> LOG: received SIGHUP, reloading configuration files
> LOG: parameter "autovacuum" changed to "off"
> LOG: auto
Em 21 de janeiro de 2013 11:31, Flavio Henrique Araque Gurgel <
fla...@4linux.com.br> escreveu:
> > > Pessoal, tem como desabilitar (temporariamente) o autovacuum sem
> > > reiniciar o serviço do PostgreSQL?
> >
> > Sim.
> > Basta alterar no conf e dar um reload ao invés de resta
> > Pessoal, tem como desabilitar (temporariamente) o autovacuum sem
> > reiniciar o serviço do PostgreSQL?
>
> Sim.
> Basta alterar no conf e dar um reload ao invés de restart.
> Para mim foi estranho, pois antes de perguntar a lista eu fiz isso, mas,
> visualizando o "top", o p
2013/1/21 Flavio Henrique Araque Gurgel
> Em 21-01-2013 10:56, Danilo Silva escreveu:
> > Pessoal, tem como desabilitar (temporariamente) o autovacuum sem
> > reiniciar o serviço do PostgreSQL?
>
> Sim.
> Basta alterar no conf e dar um reload ao invés de restart.
>
> []s
>
> Para mim foi estranho
Em 21-01-2013 10:56, Danilo Silva escreveu:
> Pessoal, tem como desabilitar (temporariamente) o autovacuum sem
> reiniciar o serviço do PostgreSQL?
Sim.
Basta alterar no conf e dar um reload ao invés de restart.
[]s
__
Flavio Henrique A. Gurgel
Líder de Projetos E
Pessoal, tem como desabilitar (temporariamente) o autovacuum sem reiniciar
o serviço do PostgreSQL?
[]s
Danilo
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Em 24-08-2012 12:13, Marcelo Silva escreveu:
> Pior que já...
Tem certeza? Cheque a visão pg_stat_user_tables. Lá tem quando foi
último vacuum e último autovacuum.
> Será que vou ter que adicionar Autovacuum em cada tabela?
Não.
Ligou, tá pra todas. Exceto se o catálogo "pg_autovacuum" (até 8.
Pior que já...
Será que vou ter que adicionar Autovacuum em cada tabela?
-Mensagem Original-
From: Euler Taveira
Sent: Friday, August 24, 2012 11:54 AM
To: Comunidade PostgreSQL Brasileira
Subject: Re: [pgbr-geral] Autovacuum
On 24-08-2012 11:32, Marcelo Silva wrote:
> Curioso
On 24-08-2012 11:32, Marcelo Silva wrote:
> Curioso que quando eu seleciono algumas tabelas ele pede pra fazer Vacuum.
>
Talvez porque o VACUUM nunca foi executado naquela tabela?
--
Euler Taveira de Oliveira - Timbira http://www.timbira.com.br/
PostgreSQL: Consultoria, Desenvolvime
Curioso que quando eu seleciono algumas tabelas ele pede pra fazer Vacuum.
Será que o pgAdmin ta doido :)
-Mensagem Original-
From: Euler Taveira
Sent: Friday, August 24, 2012 11:10 AM
To: Comunidade PostgreSQL Brasileira
Subject: Re: [pgbr-geral] Autovacuum
On 24-08-2012 10:01
On 24-08-2012 10:01, Marcelo Silva wrote:
> Estou usando a versão 9.1 no linux
>
> No postgresql.conf o Autovacuum está "on"
> Mas não achei esses parametros:
>
> 'stats_start_collector' and 'stats_row_level'
>
> Devo acrescenta-los?
>
Leia a mensagem novamente. Ele estava se referindo a versão
va
-Mensagem Original-
From: Euler Taveira
Sent: Thursday, August 23, 2012 1:49 PM
To: Comunidade PostgreSQL Brasileira
Subject: Re: [pgbr-geral] Autovacuum
On 23-08-2012 13:42, Marcelo Silva wrote:
> Devo ativar o Autovacuum como ele recomenda ou ignoro?
>
O seu autovacuum está desa
Postgres 9.1 no Linux
PpgAdmin3 1.14.3 no Windows
-Mensagem Original-
From: Euler Taveira
Sent: Thursday, August 23, 2012 1:49 PM
To: Comunidade PostgreSQL Brasileira
Subject: Re: [pgbr-geral] Autovacuum
On 23-08-2012 13:42, Marcelo Silva wrote:
> Devo ativar o Autovacuum como
On 23-08-2012 13:42, Marcelo Silva wrote:
> Devo ativar o Autovacuum como ele recomenda ou ignoro?
>
O seu autovacuum está desabilitado? Qual a versão do PGAdmin e do PostgreSQL?
A partir da 8.3, é mandatório deixar o autovacuum habilitado; ele te auxilia
em tarefas que antes eram trabalhosas de
Le 23/08/12 13:42-0300, Marcelo Silva a écrit :
> Senhores, toda vez que conecto pelo pgAdmin3 ele me dá essa mensagem abaixo
> Devo ativar o Autovacuum como ele recomenda ou ignoro?
Sempre!
--
skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra
+55 (61) 3546 7191 gTa
Senhores, toda vez que conecto pelo pgAdmin3 ele me dá essa mensagem abaixo
Devo ativar o Autovacuum como ele recomenda ou ignoro?
Inicio
Running autovacuum recommended
Introduced in PostgreSQL 8.1, the autovacuum process which was previously
implemented as an external service process is now
Em 4 de julho de 2012 13:28, Flavio Henrique Araque Gurgel
escreveu:
>> E qual seria o problema em manter um VACUUM (não FULL) rodando no CRON
>> semanalmente se houver uma janela de manutenção disponível?
>
> Se você tem janela, nenhum problema.
> Note que pra executar VACUUM não é necessário jan
Em 04-07-2012 13:23, Fabrízio de Royes Mello escreveu:
> Flávio,
>
> E como vc trata o inchaço natural das tabelas e índices? Pq somente o
> "autovacuum" não elimina isso
Ele não elimina.
Ele mantém num nível aceitável.
O funcionamento normal do PostgreSQL e seu modelo de MVCC pressupõe a
e
> E qual seria o problema em manter um VACUUM (não FULL) rodando no CRON
> semanalmente se houver uma janela de manutenção disponível?
Se você tem janela, nenhum problema.
Note que pra executar VACUUM não é necessário janela também, o banco de
dados permanece disponível.
O ruim é fazer SÓ isso,
Em 4 de julho de 2012 13:12, Flavio Henrique Araque Gurgel <
fla...@4linux.com.br> escreveu:
>
> Não concordo. Tenho servidores que funcionam há anos só com o autovacuum
> ligado e bem configurado, sem nenhuma intervenção manual.
>
> [...]
>
>
Flávio,
E como vc trata o inchaço natural das tabelas
Em 4 de julho de 2012 13:12, Flavio Henrique Araque Gurgel
escreveu:
> Em 04-07-2012 13:03, Tiago Adami escreveu:
>> Em 4 de julho de 2012 12:03, Marcelo Silva (IG) escreveu:
>>>
>>> E ai, senhores tudo na boa?
>>>
>>> Seguinte, no arquivo postgresql.conf a linha Autovacuum está ON
>>> Isso no se
Em 04-07-2012 13:03, Tiago Adami escreveu:
> Em 4 de julho de 2012 12:03, Marcelo Silva (IG) escreveu:
>>
>> E ai, senhores tudo na boa?
>>
>> Seguinte, no arquivo postgresql.conf a linha Autovacuum está ON
>> Isso no servidor Linux
>> Quando acesso o banco pelo pgAdmin3 pelo Windows ele diz que t
Em 4 de julho de 2012 12:03, Marcelo Silva (IG) escreveu:
>
> E ai, senhores tudo na boa?
>
> Seguinte, no arquivo postgresql.conf a linha Autovacuum está ON
> Isso no servidor Linux
> Quando acesso o banco pelo pgAdmin3 pelo Windows ele diz que tenho que
> habilitar o Vacuum.
> Não entendi
>
> E
E ai, senhores tudo na boa?
Seguinte, no arquivo postgresql.conf a linha Autovacuum está ON
Isso no servidor Linux
Quando acesso o banco pelo pgAdmin3 pelo Windows ele diz que tenho que
habilitar o Vacuum.
Não entendi
Estou executando de vez em quando o Vacuum manualmente
Qual o recomendável ?
Flávio
Isso mesmo, e obrigado por me corrigir na argumentação.
Valeu pela ajuda.
Em 14 de junho de 2012 17:05, Flavio Henrique Araque Gurgel <
fla...@4linux.com.br> escreveu:
>
> Em 14-06-2012 16:54, Tiago Valério escreveu:
> > Srs
> >
> > Retornando para dar um feedback e agradecendo o apoio,
Em 14-06-2012 16:54, Tiago Valério escreveu:
> Srs
>
> Retornando para dar um feedback e agradecendo o apoio, resolvemos o
> problema desabilitando o parâmetro abaixo:
>
> autovacuum_vacuum_cost_delay = -1
>
> Este parâmetro estava setado no valor default 20s.
Realmente um valor insano.
Note que
Srs
Retornando para dar um feedback e agradecendo o apoio, resolvemos o
problema desabilitando o parâmetro abaixo:
autovacuum_vacuum_cost_delay = -1
Este parâmetro estava setado no valor default 20s.
http://www.postgresql.org/docs/9.1/static/runtime-config-autovacuum.html
Neste momento o dae
Em 13 de junho de 2012 15:52, Euler Taveira escreveu:
> On 13-06-2012 14:25, Tiago Valério wrote:
> > Possuimos funções que criam tabelas temporárias do tipo on commit drop,
> estas
> > funções rodam frequentemente e isto esta gerando um gargalo na execução
> do
> > daemon autovacuum conforme re
On 13-06-2012 14:25, Tiago Valério wrote:
> Possuimos funções que criam tabelas temporárias do tipo on commit drop, estas
> funções rodam frequentemente e isto esta gerando um gargalo na execução do
> daemon autovacuum conforme resumo abaixo.Em especial gostaria de citar a
> pg_catalog.pg_attribut
Em 13-06-2012 15:18, Tiago Valério escreveu:
> PostgreSQL 9.1.2 on amd64-portbld-freebsd8.2, compiled by cc (GCC)
> 4.2.1 20070719 [FreeBSD], 64-bit
Considere atualizar o mais rápido que puder pra 9.1.4. Dezenas de bugs
corrigidos na última atualização. E são bugs bem críticos.
>
>
>
> > autovacuum=> on
> > autovacuum_analyze_scale_factor=> 0.1
> > autovacuum_analyze_threshold =>50
> > autovacuum_freeze_max_age=>2
> > autovacuum_max_workers=>10
> > autovacuum_naptime => 60
> > autovacuum_vacuum_cost_delay => 20
> > autovacuum_vacuum_cost_limit =>-1
> > autovacuum_vacu
> autovacuum=> on
> autovacuum_analyze_scale_factor=> 0.1
> autovacuum_analyze_threshold =>50
> autovacuum_freeze_max_age=>2
> autovacuum_max_workers=>10
> autovacuum_naptime => 60
> autovacuum_vacuum_cost_delay => 20
> autovacuum_vacuum_cost_limit =>-1
> autovacuum_vacuum_scale_factor=>0.2
Srs
O seguinte problema nos ocorre:
Possuimos funções que criam tabelas temporárias do tipo on commit drop,
estas funções rodam frequentemente e isto esta gerando um gargalo na
execução do daemon autovacuum conforme resumo abaixo.Em especial gostaria
de citar a pg_catalog.pg_attribute com seus 4
>
>
> Sim, é uma prevenção para evitar perda de dados. Você deveria estar com o
>> autovacuum ligado ou, no mínimo, fazer vacuums manuais regularmente.
>> Para não ter que se preocupar com isso, mantenha o autovacuum ligado e bem
>> configurado.
>>
>
> Tenho as rotinas de manutenção rodando diariam
Em 17 de maio de 2011 13:22, Emanuel Araújo escreveu:
>
>
> Sim, é uma prevenção para evitar perda de dados. Você deveria estar com o
>> autovacuum ligado ou, no mínimo, fazer vacuums manuais regularmente.
>> Para não ter que se preocupar com isso, mantenha o autovacuum ligado e bem
>> configurad
Sim, é uma prevenção para evitar perda de dados. Você deveria estar com o
> autovacuum ligado ou, no mínimo, fazer vacuums manuais regularmente.
> Para não ter que se preocupar com isso, mantenha o autovacuum ligado e bem
> configurado.
>
Tenho as rotinas de manutenção rodando diariamente, mas man
Srs. Estou com autovacuum off e mesmo assim o banco inicio esse processo,
porque ? É algum tipo de prevenção? Como saber que ele vai iniciar esse
processo ou se está perdo disso ... ?
Sim, é uma prevenção para evitar perda de dados. Você deveria estar com o
autovacuum ligado ou, no mínimo, fazer
Srs. Estou com autovacuum off e mesmo assim o banco inicio esse processo,
porque ? É algum tipo de prevenção? Como saber que ele vai iniciar esse
processo ou se está perdo disso ... ?
autovacuum: VACUUM ANALYZE pg_catalog.pg_largeobject (to prevent wraparound)
--
*Atenciosamente,
Emanuel Araúj
Entendo...
Vou fazer as devidas análises e adotar a melhor política.
Agradeço a todos.
--
Atenciosamente,
Emanuel Araújo
http://eacshm.wordpress.com
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-
> Minha estrutura de banco de dados se renume a um cluster que roda com
> vários databases, em média 50 bancos em um único cluster. Temos
> rotinas que rodam diariamente com várias transações e muitas
> alterações, usamos OIDS (Arquivos dentro dos Bancos) em larga escala.
>
> Rodamos semanalmente
Em 22-12-2010 10:22, Emanuel Araújo escreveu:
> Rodamos semanalmente um vacuum full nas bases, e não usamos
> autovacuum, decidimos isso com receio de perda de performance já que o
> banco é constantemente exigido.
>
> Alguém poderia me ajudar com casos de uso ou explicar os benefícios
> e/ou malef
Amigos da Lista,
Minha estrutura de banco de dados se renume a um cluster que roda com
vários databases, em média 50 bancos em um único cluster. Temos
rotinas que rodam diariamente com várias transações e muitas
alterações, usamos OIDS (Arquivos dentro dos Bancos) em larga escala.
Rodamos semana
Bom dia,
Olhando teu arquivo de configuração, o autovacuum não está desabilitado.
Veja esta linha:
#autovacuum = off # Enable autovacuum subprocess? 'on'
Ela está comentada, assim precisas descomentar essa linha e recarregar as
configurações do Pg para que ele fique realmente desabilitado.
Olá Pessoal,
Estou com uma dúvida, por opção nossa resolvemos não deixar o autovacuum no
automático e sim no manual (cron nas madrugadas), porém percebemos que ainda
assim vemos com frequencia vários processos com o autovacuum, será que
fizemos algo em desacordo?
Estamos enfrentando uma dificu
Aluisio Gouveia wrote:
> O que quiz dizer é que mesmo rodando um vacuum full regularmente e
> imediatamente antes de um processo de dump/restore, o banco restaurado
> vai ficar menor que o banco original. Constatei isso em bancos na versao
> 8.1, nao repeti os testes na 8.2 e 8.3
>
E a tendênc
André Volpato wrote:
> É apenas uma maneira de provar que ele reduz espaço.
>
euler=# select relname,pg_catalog.pg_relation_size(oid) from pg_class
where relname ~ 'foo';
relname | pg_relation_size
--+--
foo | 1613824
foo_pkey | 3596288
(2 re
André Volpato escreveu:
> Euler Taveira de Oliveira escreveu:
>
>> Aluisio Gouveia wrote:
>>
>>
>>> O amigo André Volpato confirmou que o reindex libera espaco, mas uma
>>> forma bem facil de perceber isso é fazer um dump/restore pos-reindex, vc
>>> vai perceper que o banco restaurado
Euler Taveira de Oliveira escreveu:
>> O amigo André Volpato confirmou que o reindex libera espaco, mas uma
>> forma bem facil de perceber isso é fazer um dump/restore pos-reindex, vc
>> vai perceper que o banco restaurado fica exatamente com o tamanho que
>> tinha antes do dump e o mesmo nao ac
Euler Taveira de Oliveira escreveu:
> Aluisio Gouveia wrote:
>
>> O amigo André Volpato confirmou que o reindex libera espaco, mas uma
>> forma bem facil de perceber isso é fazer um dump/restore pos-reindex, vc
>> vai perceper que o banco restaurado fica exatamente com o tamanho que
>> tinha
Aluisio Gouveia wrote:
> Na verdade meu servidor beta esta rodando com versao 8.3.1 mais estou
> estudando a possibilidade de migrar os outros servidores para a mesma
> versão e habilitar o autovacuum, entao se alguem ja estiver utilizando e
> puder postar aqui sua experiencia pq percebi que mu
Aluisio Gouveia escreveu:
>
>
> >> 4) Falando em liberar espaço, um reindex geral no banco de vez em
> >> quando, contribui para a performace ou apenas libera espaco?
> >>
> >>Conforme comentei na questão acima, é necessário saber o que você
> considera de tempos em tempos. Uma vez por sem
Leandro DUTRA wrote:
> Geralmente melhorias de desempenho por reconstruir índices são
> irrelevantes e não compensam o esforço.
>
Se você tem uma tabela com muitas modificações e o HOT não ajuda, você
tem um ganho em espaço e performance.
--
Euler Taveira de Oliveira
http://www.timbira.
>> jota.comm escreveu:
>> 3) Estando o autovacuum habilitado, seria bom rodar um vacuumdb -f de
>>vez em quando apenas para liberar espaço?
>>
>>Conforme o Sebastian comentou, é necessário saber o que você
considera de vez em quando. Uma vez por semana? De 15 em 15 dias? Isso
também depende
Olá, pessoal
Na verdade depois que eu respondi sobre a liberação de espaço por índices já
esperava a resposta que o André comentou, é que não consegui me expressar
bem, na verdade quando ocorre o processo de reindexação vai ocorrer uma
reorganização na árvore e consequentemente os arquivos serão m
3) Estando o autovacuum habilitado, seria bom rodar um vacuumdb -f de
vez em quando apenas para liberar espaço?
Conforme o Sebastian comentou, é necessário saber o que você considera
de vez em quando. Uma vez por semana? De 15 em 15 dias? Isso também
depende muito de como é o seu banco de dado
2008/5/19 André Volpato <[EMAIL PROTECTED]>:
>
> O reindex libera espaço sim, na maioria das vezes. Isso porque os
> índices são recriados do zero.
> Quanto a performance, creio que melhore também, uma vez que os arquivos
> do índice estarão menores e contínuos no disco.
Geralmente melhorias de de
jota.comm escreveu:
>
> 4) Falando em liberar espaço, um reindex geral no banco de vez em
> quando, contribui para a performace ou apenas libera espaco?
>
> Conforme comentei na questão acima, é necessário saber o que você
> considera de tempos em tempos. Uma vez por semana? 10 dias? Eu,
> desco
Olá, pessoal
1) Na versao 8.3 os parametros stats_start_collector e stats_row_level
estao implicitos, ou preciso habilitar parametros similares na 8.3 para um
pleno funcionamento do autovacuum?
Eles estão implícitos, não existem mais no postgresql.conf. A única coisa
que você tem que verificar
On Fri, May 16, 2008 at 3:30 PM, Aluisio Gouveia
<[EMAIL PROTECTED]> wrote:
>
> Pessoal,
Olá!
> Tenho servidores rodando com 8.2 e um 8.3 rodando como beta. Nos
> servidores 8.2 tenho uma rotina no cron que roda o vacuumdb uma vez por dia,
> li aqui na lista que o autovacuum apartir da 8.3 esta
Pessoal,
Tenho servidores rodando com 8.2 e um 8.3 rodando como beta. Nos
servidores 8.2 tenho uma rotina no cron que roda o vacuumdb uma vez por dia,
li aqui na lista que o autovacuum apartir da 8.3 esta melhor e
confiável, entao habilitei no servidor 8.3 mas estou com algunas dúvidas
que segu
78 matches
Mail list logo
