On 04-05-2016 09:04, Daniel Luiz da Silva wrote: > O parâmetro autovacuum_vacuum_cost_delay está em 20 ms. Sobre o FREEZE, > acredito que não seria o caso, porque na teoria, ele só seria problema > se não estivesse habilitado o auto_vacuum, correto? > Qualquer comando VACUUM pode realizar "freeze" de tuplas; os parâmetros "freeze" controlam isso.
> A operação FREEZE, congela as linhas para não ser alterada e reinicia > o contador de transações, correto? Porque seria realizado essa > operação nesse momento? > Muitos confundem isso: "congelar" não quer dizer "não poder alterar" tuplas. "Congelar" quer dizer "substituir o id de transação presente nas tuplas para um valor mais recente". Esse id de transação nas tuplas é que controla a visibilidade das mesmas nas transações. Substituí-lo nas tuplas é necessário para evitar que após algum (longo) tempo acabe ids de transação que serão atribuídos a novas transações. > 24MB eu medi através do comando "top" do linux, encontrei o PID da > operação e calculei o consumo da memória, porque no comando top é > exibido a porcentagem consumida de memória para cada processo, com base > na memória total, apenas fiz um calculo para chegar nos 24MB. > Sobre a quantidade de 6Bytes por tupa não vigente, se multiplicar 6Bytes > * 55577 (tuplas não vigentes) = 333462 Bytes / 1024 (transformar para > KB) = 325 KB aproximadamente, isso não equivale a 24MB. > Como eu falei, 24 MB *não* é a memória utilizada para rastreio das tuplas não vigentes. Não se esqueça que o próprio processo servidor já tem memória alocada. -- Euler Taveira Timbira - http://www.timbira.com.br/ PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento _______________________________________________ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
