Em 05-09-2013 15:31, JotaComm escreveu:
    Como autovacuum_vacuum_cost_limit = -1, ele usa vacuum_cost_limit.
    Tá quanto lá?


postgres=# SHOW vacuum_cost_delay;
  vacuum_cost_delay
-------------------
  0
(1 row)

Cara, fiz uma confusão aqui.

Acabei de olhar um post do Tom Lane (a orelha dele deve estar quente hoje) explicando que a operação de vacuum para realocar os xids (prevent wraparound) tem redução de velocidade proposital. Então, o valor de vacuum_cost_limit e vacuum_cost_delay não vai ser observado.

Ele é mais lento mesmo.

    Mas faz assim pra acabar o mais rápido possível (só que vai fazer
    I/O pra burro e interferir em transações, então, faça em horário de
    baixo movimento):
    SET vacuum_cost_delay = 0;
    VACUUM ANALYZE tabela;


Pior é que o vaccum_cost_delay já está em 0.

Então, um vacuum manual vai respeitar isso, o autovacuum to prevent wraparound não vai. Então, o vacuum manual vai ser mais rápido.


    Se não der tempo/resolver, um dump/restore da tabela seria bem
    vindo, já que ela não é tão grande, ou um CLUSTER.


O grande problema é que esta tabela deriva muitos relacionamentos, e
isso será um problema, mas senão tiver solução, esta será a saída.

Usando CLUSTER/VACUUM FULL você não precisa se preocupar com relacionamentos, só com o lock exclusivo na tabela enquanto a operação rola.

Todavia, e já vi isso acontecer em cluster 8.3, o autovacuum to prevent wraparound terminou. Um dia ele termina. Era um banco de dados extremamente ocupado e não houve bloqueio de uso da tabela, ele terminou em tempo.

Ah, a cada vez que se tenta cancelar o backend, parte do trabalho já feito pode se perder e o processo começa do zero. Então, evite cancelar isso.

Se você estiver realmente preocupado, você pode subir o PostgreSQL em modo monousuário e fazer o vacuum na tabela sem ninguém te atrapalhando.

[]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: [email protected]
______________________________
FREE SOFTWARE SOLUTIONS
_______________________________________________
pgbr-geral mailing list
[email protected]
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Responder a