> Mas acredito que o impacto esteja justamente no metodo fsync pois o wal quer > garantir que isto esteja em uma area nao volatil.Correto?Por mais que eu > utilize fsync=off .
Se fsync=off o PostgreSQL deixará o trabalho de persistência em disco como uma decisão do S.O. Vai acabar tudo em buffer. Isso vale apenas para escrita, modificação de dados. Use fsync=off somente se seus dados forem descartáveis. > escrita grandes .Por exemplo: > Para update de 10 milhoes de registros 279 sec .Alterando os parametros > estes segundos nao parecem tem grandes ganhos nem para mais ou para > menos.Percebo pelo zpool iostat que as escritas entre os pools de pg_xlog e > dados nao se alteram. ZFS para funcionar bem: - aplique todos os patches do Solaris relacionados ao ZFS; - faça principalmente tuning go cache do ARC, ele costuma causar congelamentos no S.O. quando enche demais; - siga este guia: http://www.solarisinternals.com/wiki/index.php/ZFS_Evil_Tuning_Guide Em tempo: se você quer alterar 10 milhões de linhas, o tempo certamente será alto. O PostgreSQL precisa logar isso no WAL. O tempo dependerá do volume de linhas e tamanho das alterações em páginas (normalmente de 8kiB cada). Se você quizer evitar a escrita em WAL (log adiantado de escrita), procure utilizar PostgreSQL 9.1 e sua nova funcionalidade "Unlogged Tables". Lembrando que os dados tem de ser descartáveis, pois não há garantia de persistência (o D do ACID, durabilidade). []s Flavio Gurgel _______________________________________________ pgbr-geral mailing list [email protected] https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
