Pra mim o gzip sempre comprimiu em níveis mais
que satisfatórios. Por exemplo, um log de transação quase vazio fica com
cerca de 1MB e numa atividade maior costuma ficar de 4MB a 6MB (se
não me
engano), isso porque o PostgreSQL sempre inicia esse arquivo todo com
bytes
zero.
Uhm, eu não sabia disso. Vou verificar no código, mas eu sempre lidei
com o fato de que o PostgreSQL aproveitava arquivos existentes
renomeando-os, afinal, criar arquivos zerados com 16 MiB a cada vez
custa "caro" num servidor ocupado.
Não olhei código, mas a nossa excelente documentação:
http://www.postgresql.org/docs/9.3/static/continuous-archiving.html
No trecho:
"In an abstract sense, a running PostgreSQL system produces an
indefinitely long sequence of WAL records. The system physically divides
this sequence into WAL segment files, which are normally 16MB apiece
(although the segment size can be altered when building PostgreSQL). The
segment files are given numeric names that reflect their position in the
abstract WAL sequence. When not using WAL archiving, the system normally
creates just a few segment files and then "recycles" them by renaming
no-longer-needed segment files to higher segment numbers. It's assumed
that segment files whose contents precede the checkpoint-before-last are
no longer of interest and can be recycled."
Logo, os segmentos são reciclados sempre que possível, portanto,
segmentos nem sempre tem montes de zeros. Ao renomear o segmento, o
PostgreSQL coloca um byte de controle onde seria o final desse segmento.
Após esse byte de controle, pode sim haver "sujeira" da utilização
anterior desse segmento, afinal, eles têm sempre exatos 16 MiB (na
compilação padrão).
[]s
Flavio Gurgel
_______________________________________________
pgbr-geral mailing list
[email protected]
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
