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. Como vi que realmente o full no final é focado em liberação de espaço e não é esse o caso parti pro vacuum analyze mesmo. O problema em fazer o dump/restore é mais vaidade que problema, pois consegui uma boa janela para trabalhar no sistema. É que não considero que sempre terei uma janela de mais de 1 hora, então estava procurando a melhor alternativa para solução do problema. Que é exatamente o que você citou, estudar as tabelas, verificar quais podem ter aplicação de CLUSTER nos índices e etc... Valeu as dicas e obrigado a todo o pessoal que contribuiu.
2012/8/24 Matheus de Oliveira <[email protected]> > > 2012/8/23 Bruno Silva <[email protected]> > >> É 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 medida rápida para auxiliar nisso é aplicar os casts implícitos [1], o > ideal mesmo é alterar a aplicação, mas sei que nem sempre é possível. > > Uma recomendação é aplicar os CASTS ao encontrar os erros, assim você só > aplica o que realmente é necessário para a aplicação e vai tentando ir > corrigindo-a com o tempo. > > >> Então estou com essa preocupação diária. >> Estava lendo diversos documentos, inclusive da lista, que dizem que o VF >> é muito honeroso. Então estou pensando se não é melhor fazer um >> dump/restore, ou um vacuum analyze e um reindexdb. >> > > Em determinadas situações o VACUUM FULL pode até degradar (por um tempo) o > desempenho do banco. > Só use um VACUUM FULL se você realmente "precisa liberar espaço em disco", > e nada mais. > Aliás, tome cuidado também, que o processo de VACUUM FULL usa bastante > espaço em disco para ser feito. > Veja na documentação [2]: > > Selects "full" vacuum, which may reclaim more space, but takes much > longer and exclusively locks the table. > ... > The FULL option is not recommended for routine use, but may be useful in > special cases. An example is when you have deleted most of the rows in a > table and would like the table to physically shrink to occupy less disk > space. VACUUM FULL will usually shrink the table more than a plain > VACUUMwould. The > FULL option does not shrink indexes; a periodic REINDEX is still > recommended. In fact, it is often faster to drop all indexes, VACUUM FULL, > and recreate the indexes. > > > De qualquer forma, qual o motivo que você está tentando fazer isso? As > tabelas estão lentas de acessar? Rode um VACUUM VERBOSE e dê uma olhada, > talvez você não precise de nada, se não um simples VACUUM ANALYZE. > > De qualquer forma, se você puder fazer um dump/restore, não há tanto > problema assim não, ele realmente limpa tudo, mas o CLUSTER é ainda melhor > porque ordena os dados das tabelas de acordo com algum índice. > Uma forma simples de você automatizar o CLUSTER geral é olhar na tabela > pg_stat_user_indexes para saber os índices mais usados de cada tabela (nem > sempre são de fato os melhores) ou então a chave primária. > > Em geral o autovacuum fará bem todo esse trabalho por você (mais verdade > nas versões mais novas), então tente configurá-lo bem. > > >> Não estou interessado em fazer dump/restore por achar que dessa forma não >> estarei realmente aplicando o meio certo. >> >> > Não é que seja errado, mas dump/restore tem que ter parada total do > sistema, e garantia que NINGUÉM faça nenhuma atualização (você tem que > garantir por si só, o PostgreSQL não faz isso). Além disso, tem o que já > citei, o CLUSTER > > > [1] http://wiki.postgresql.org/wiki/File:Pg83-implicit-casts.sql > [2] http://www.postgresql.org/docs/9.1/static/sql-vacuum.html > > -- > Matheus de Oliveira > > _______________________________________________ > pgbr-geral mailing list > [email protected] > https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral > >
_______________________________________________ pgbr-geral mailing list [email protected] https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
