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 é
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
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
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
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
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
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
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
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:
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,
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
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.
>
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
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
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 /
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
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
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
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
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
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
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
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
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
Euler,
Sem replicação.
name | current_setting
|source| sourcefile
| sourceline
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]
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
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
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
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
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
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
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
[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.
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
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
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
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
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
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 é
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
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
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
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
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,
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
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
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
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.
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,
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;
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,
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
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
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
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.
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
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
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
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
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
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
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
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 é:
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
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,
--
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
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.
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
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
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
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
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á
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.
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 ?
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
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
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
É 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
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
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
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
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
@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
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
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
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
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
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
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
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
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
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
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ê
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.
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
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
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
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
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 - 100 de 116 matches
Mail list logo