On 04-05-2016 14:47, Daniel Luiz da Silva wrote: > Euller, > > Tem como rastrear o XID de uma tupla? >
[..por favor não faça top-posting..] Existem as colunas xmin e xmax... recomendo dar uma olhada nessa apresentação do Bruce: http://momjian.us/main/writings/pgsql/mvcc.pdf Tem gravações dessa apresentação no youtube: https://www.youtube.com/watch?v=bfGEct9wSTM Att, -- Fabrízio de Royes Mello Timbira - http://www.timbira.com.br/ PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento Fabrízio e Euller, Obrigado pelas observações. Mas ainda estou estudando o assunto porque o comportamento é muito curioso. Minha situação, eu continuo com tabelas inchadas, ou seja, com um tamanho em espaço em disco muito maior que deveria. Fiz a recriação da tabela, anteriormente contendo 6mil páginas aproximadamente baixou para 150 páginas, exibindo que existe um inchaço muito grande. Com tudo, li a documentação do Postgres sobre autovaccum, fillfactor, freeze e cluster, inclusive li alguns post antigos da lista. Mas fiquei com mais dúvida, segue dúvidas: - em resumo para que existe o controle de transações, através do XID (idiota a pergunta?), significa que caso eu diminua o tamanho autovaccum_freeze_max_age e autovaccum_freeze_min_age, será realizado freeze mais vezes em conjunto com autovaccum, por tanto, será reiniciado o contador de XID para o valor autovaccum_freeze_min_age e trabalhará entre o mínimo e máximo. Se eu colocar um valor muito baixo, no autovaccum_freeze_min_age (próximo a zero) e muito alto autovaccum_freeze_max_age (próximo de 2 bilhões), a quantidade de vezes que será disparado autovacuum com freeze será menor, entretanto, terá a principio um custo maior para realizar essa operação, porque terá mais XID para substituir? Isso tem impacto caso de disaster recovery? Qual problema de trabalhar com range de XID muito curtos/longos? - testei a reordenação de páginas e concluí que as páginas de uma tabela, só são realizadas com VACCUM FULL/CLUSTER, e que caso alterasse o valor do fill-factor, para um valor de acordo com a quantidade de update que tenho diariamente nessa tabela, ou seja, para um valor que mantenha um valor de desorganização de páginas controlável, o fill-factor teria sentido apenas como um "ajudante", e teria que rodar uma manutenção de acordo com o nível de organização que quero manter, porém, causaria lock exclusivo durante esse tempo, correto? Porque, segundo a documentação, a manutenção deverá ser realizada pelo auto-vaccum e vaccum, evitando o VACUMM FULL. Depois dessa analise fiquei curioso por isso, porque dificilmente eu conseguirei controlar a organização sem VACCUM FULL/CLUSTER, então, como isso é possível? - setando um index como CLUSTER, o que aconteceria por baixo do pano? Isso teria impacto caso de um desaster recovery? Pessoal, obrigado pelo esclarecimento, acho que isso servirá para outras pessoas também. _______________________________________________ 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
