On 03-05-2016 16:17, Daniel Luiz da Silva wrote: > - mesmo utilizando 24MB, na sessão, e demorando 40 mintuos, porque não > utilizou total disponível 32MB, como funciona o rastreio de tuplas não > vigentes? > Ele pode ter demorado tanto tempo assim porque a tabela está muito inchada e/ou o autovacuum_vacuum_cost_delay está alto. Outra teoria é porque ele estava fazendo FREEZE. Quanto ao tamanho, como você mediu os 24 MB? Para o rastreio são geralmente 6 bytes por tupla não vigente. Além disso, o worker não é só memória para rastreio. Como você mediu 24 MB? RES? VIRT?
> - é um processo do autovacuum, e não wrap-around; > Tenha em mente que o autovacuum pode disparar para realizar ação anti-wraparound. > - Segue estatísticas da tabela: > relname; > seq_scan;seq_tup_read;idx_scan;idx_tup_fetch;n_tup_ins;n_tup_upd;n_tup_del;n_tup_hot_upd;n_live_tup;n_dead_tup;last_vacuum;last_autovacuum;last_analyze;last_autoanalyze > "tbsession";33874;63090745;64590117;62505457;1051135;31172552;1050387;29656406;2159;55577;"30/04/2016 > 13:07:15";"03/05/2016 16:01:44";"30/04/2016 13:07:15";"03/05/2016 16:01:45" > Tamanho total 11.3GB > A sua tabela está exageradamente inchada (2159 tuplas vigentes e 55.577 tuplas não-vigentes). Para ter 11 GB, deve haver muitas páginas quase vazias. Neste caso, eu aconselho executar o VACUUM FULL para voltar ao tamanho normal. O autovacuum está desabilitado nessa tabela? > Minha preocupação final além disso é porque trata-se uma tabela com muio > update, ou seja, muito inchada, porém, estou estudando para entender > e tratar essa tabela. > Talvez você precise de: (i) valores personalizados do autovacuum ou (ii) uma rotina manual. -- Euler Taveira Timbira - http://www.timbira.com.br/ PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento _______________________________________________ pgbr-geral mailing list [email protected] https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
