PostgreSQL fillfactor
26 de Janeiro de 2016, 20:57 - sem comentários aindaEste artigo foi escrito por telles
Precisei fazer uma prova simples para um cliente para mostrar como o parâmetro de storage FILLFACTOR afeta uma tabela e como verificar a sua eficiência. Toda vez que um UPDATE é executado no PostgreSQL, ele marca a tupla atualizada para remoção posterior e cria um novo registro. Porém, se no bloco onde o dado está gravado houver espaço sobrando, o PostgreSQL pode fazer a atualização dentro do próprio bloco, utilizando um recurso conhecido como “Heap Only Tuples”, ou HOT. Quando foi introduzido no PG 8.3, foi considerado um divisor de águas, aumentando muito a performance do banco e diminuindo o uso do Vacuum. Mas você pode dar uma ajuda para o HOT funcionar, deixando mais espaço livre para ele trabalhar em tabelas que sofrem muitas atualizações. Vejamos uma demonstração simples.
Primeiro vamos criar uma tabela nova e verificar as estatísticas e depois rodar um UPDATE:
tst=# CREATE TABLE abizi AS SELECT * FROM pg_class ; SELECT 1009 tst=# SELECT n_tup_ins, n_tup_upd, n_tup_hot_upd, n_live_tup, n_dead_tup FROM pg_stat_user_tables WHERE relname = 'abizi'; n_tup_ins | n_tup_upd | n_tup_hot_upd | n_live_tup | n_dead_tup -----------+-----------+---------------+------------+------------ 1009 | 0 | 0 | 1009 | 0 (1 row) tst=# UPDATE abizi SET relname = 'abizi'; UPDATE 1009 tst=# SELECT n_tup_ins, n_tup_upd, n_tup_hot_upd, n_live_tup, n_dead_tup FROM pg_stat_user_tables WHERE relname = 'abizi'; n_tup_ins | n_tup_upd | n_tup_hot_upd | n_live_tup | n_dead_tup -----------+-----------+---------------+------------+------------ 1009 | 1009 | 5 | 1009 | 1009 (1 row)
Note que após a atualização, os 1009 registros foram atualizados. Ao olhar o campo n_tup_hot_upd, ou seja número de tuplas que realizaram o HOT durante o UPDATE vemos que apenas 5 foram atualizados com o HOT.
Agora vamos criar novamente a tabela e antes de popular ela vamos ajustar o FILLFACTOR em 90:
tst=# DROP TABLE abizi; DROP TABLE tst=# CREATE TABLE abizi AS SELECT * FROM pg_class WITH NO DATA; SELECT 0 bbtmd=# ALTER TABLE abizi SET (fillfactor = 90); ALTER TABLE tst=# INSERT INTO abizi SELECT * FROM pg_class ; INSERT 0 1012 tst=# UPDATE abizi SET relname = 'abizi'; UPDATE 1012 tst=# SELECT n_tup_ins, n_tup_upd, n_tup_hot_upd, n_live_tup, n_dead_tup FROM pg_stat_user_tables WHERE relname = 'abizi'; n_tup_ins | n_tup_upd | n_tup_hot_upd | n_live_tup | n_dead_tup -----------+-----------+---------------+------------+------------ 1012 | 1012 | 116 | 1012 | 1012
Note que agora o número de registros que usaram o HOT subiu para 116. Se fizermos a mesma coisa com um FILLFACTOR em 70:
tst=# DROP TABLE abizi; DROP TABLE tst=# CREATE TABLE abizi AS SELECT * FROM pg_class WITH NO DATA; SELECT 0 tst=# ALTER TABLE abizi SET (fillfactor = 70); ALTER TABLE tst=# INSERT INTO abizi SELECT * FROM pg_class ; INSERT 0 1012 tst=# UPDATE abizi SET relname = 'abizi'; UPDATE 1012 tst=# SELECT n_tup_ins, n_tup_upd, n_tup_hot_upd, n_live_tup, n_dead_tup FROM pg_stat_user_tables WHERE relname = 'abizi'; n_tup_ins | n_tup_upd | n_tup_hot_upd | n_live_tup | n_dead_tup -----------+-----------+---------------+------------+------------ 1012 | 1012 | 449 | 1012 | 1012
Por fim com FILLFACTOR EM 50:
bbtmd=# DROP TABLE abizi; DROP TABLE tst=# CREATE TABLE abizi AS SELECT * FROM pg_class WITH NO DATA; SELECT 0 tst=# ALTER TABLE abizi SET (fillfactor = 50); ALTER TABLE tst=# INSERT INTO abizi SELECT * FROM pg_class ; INSERT 0 1012 tst=# UPDATE abizi SET relname = 'abizi'; UPDATE 1012 tst=# SELECT n_tup_ins, n_tup_upd, n_tup_hot_upd, n_live_tup, n_dead_tup FROM pg_stat_user_tables WHERE relname = 'abizi'; n_tup_ins | n_tup_upd | n_tup_hot_upd | n_live_tup | n_dead_tup -----------+-----------+---------------+------------+------------ 1012 | 1012 | 1012 | 1012 | 1012 (1 row)
Note que aumentar o valor o FILLFACTOR significa também aumentar o volume de espaço em disco utilizado. No nosso exemplo, a tabela que com 100% de FILLFACTOR (o padrão) ocupava 208KB ocupou 424KB com 50%.
O negócio é acompanhar as estatísticas da sua base e verificar onde você tem tabelas com tamanho menor e alto volume de UPDATEs. Nestas tabelas, ajustar o FILLFACTOR, AUTOVACUUM e AUTOANALYZE é vital para um bom desempenho. Tabelas pequenas às vezes passam desapercebidas pelos olhos dos DBAs, mas podem ser grande fonte de dor de cabeça se forem utilizadas com frequência e não forem ajustadas de maneira correta.
O artigo PostgreSQL fillfactor apareceu primeiro em Savepoint.
Concurso “Melhor artigo sobre PostgreSQL”
12 de Janeiro de 2016, 21:15 - sem comentários aindaEste artigo foi escrito por telles
Como eu disse antes, vou mandar uma garrafa de vodka direto de Moscou que vou trazer do PGConf RU. Aquele que escrever o melhor artigo até o final do carnaval.
Tem um zilhão de coisas que eu gostaria de escrever e não tive tempo ainda, então aqui vão algumas idéias:
- Novas tecnologias sobre Storage e Discos e como ajustar o PostgreSQL para tirar o melhor proveito delas;
- BDR, replicação bidirecional como nunca vimos antes. Está na crista da onda.
- Uma boa comparação de tecnologias de replicação / cluster. Tem um monte, vai por mim. O povo tem dificuldade de escolher, a gente precisa dar uma mão!
- Novos comandos SQL de de UPSERT e CUBE, ROLLUP e GROUPING SETs. Tem muita coisa legal para mostrar aqui. Só montar seus exemplos e demonstrar no psql!
- Demonstração do Row Locks Security. Segurança avançada é algo muito procurado. Seria legal demonstrar também um pouco das extenssões chkpass, passwordcheck e pgcrypto.
- Comparações de desempenho com índices BRIN, rowlock, sort e outras melhorias de desempenho do 9.5. Se puder fazer um comparativo com muitos processadores, seria lindo.
- Ideias criativas com as novas funcionalidades de FDW. Dá para fazer coisas mirabolantes, quais as suas ideias?
- Tipos de dados, propriedades e funções. São tantos tipos de dados, fazem tantas coisas bacanas. A gente tem que divulgar mais isso. Intervalos por exemplo resolvem problemas muito complexos de forma elegante. Quem usa bem tipos avançados, sempre tem um bom exemplo para dar.
- Testes com algumas ferramentas novas de monitoramento e desenvolvimento… tem coisa boa no ar por aí.
- DataFiller, ferramenta para geração de dados aleatórios. Algo que pode ser muito útil, fiquei de testar faz um tempo.
Bom, ideias não faltam, com um pouco de cerveja e bom papo surgem dezenas! Só colocar a mão na massa, ou melhor, a mão no teclado.
O artigo Concurso “Melhor artigo sobre PostgreSQL” apareceu primeiro em Savepoint.
10 anos de PGBR
8 de Janeiro de 2016, 13:57 - sem comentários aindaEste artigo foi escrito por telles
Ok, ok… antes que alguém reclame, a comunidade de PostgreSQL no Brasil começa no final da década de 90 numa lista de discussões por e-mail no Yahoo. Mas o que houve é que em meados dos anos 2005 a turma começou a se esbarrar cada vez mais com frequência nos eventos de Software Livre pelo Brasil. Particularmente no FISL e o saudoso CONISLI. Foi no CONISLI de 2006 no Anhembi que a turma se juntou e decidiu tomar alguns passos mais ousados. Foi a partir daí que a comunidade passou a se organizar um pouco mais formalmente. A CELEPAR passou a hospedar num servidor compartilhado com a comunidade do BROffice um wiki, uma lista de discussões, depois um planeta e um site.
Também foi a partir daí que decidimos realizar o nosso primeiro evento de PostgreSQL só nosso, o PGCon Brasil 2007.
Para comemorar estes 10 anos na comunidade, um plano ousado para 2016! Vamos brincar com o número 10 e traçar algumas metas….
- 10 blogs falando sobre PostgreSQL.
- 10 podcasts, vídeos, hangouts sobre PostgreSQL.
- 10 patches novos no PostgreSQL e/ou novas extensões.
- 10 PGDays, o primeiro já está marcado para março, em Curitiba.
- 10 palestras em eventos internacionais.
- 10 palestrantes internacionais no PGBR 2016.
Está na hora do pessoal se mexer agora. Vou iniciar minha singela contribuição presenteando o melhor artigo sobre PostgreSQL escrito até o final do carnaval (em 10/02/2016). Basta colocar um link para o SAVEPOINT e publicar o artigo na Internet. O melhor artigo vai ganhar uma garrafa de Vodka que eu vou trazer da Rússia no PGConf RU 2016. Se você já tem um blog, está na hora de tirar a poeira dele, se não, é uma boa hora para começar. Assunto para escrever não falta.
O artigo 10 anos de PGBR apareceu primeiro em Savepoint.
Posso usar o PostgreSQL 9.5 em produção hoje?
8 de Janeiro de 2016, 12:30 - sem comentários aindaEste artigo foi escrito por telles
Hoje me perguntaram se a versão do postgres 9.5 lançada ontem já pode ser colocada em produção. A resposta correta é “depende”, como todo bom consultor irá dizer, para praticamente qualquer pergunta que você fizer. Vamos aos fatos:
- As versões X.Y.0 são testadas pelos desenvolvedores e entusiastas durante o desenvolvimento e particularmente durante o lançamento do Release Candidate. Se após o lançamento do RC nenhum bug for encontrado durante os testes a versão é liberada. Isto significa que o PostgreSQL só libera uma nova versão quando todos os bugs encontrados são eliminados.
- Preste atenção na frase anterior… falamos de “bugs encontrados”. Sabe como é… por mais que você teste, sempre passa alguma coisa. E durante toda a vida de um software, sempre haverão novos bugs descobertos, ainda mais quando se tratar de um software grande e complexo como um SGDB. É por isso que periodicamente são lançados patches com correções para os erros e vulnerabilidades encontradas com o tempo.
- Lançada a versão X.Y.0, as pessoas em geral saem da faze de testes e passam para a homologação, onde o SGDB é colocado em um ambiente mais parecido com a produção possível e onde usuários passam a testar a base. Esse processo costuma levar algumas semanas ou meses.
- Sistemas periféricos, mais simples ou menos críticos, costumam serem migrados primeiro. Os demais sistemas costumam aguardar pelo menos a liberação do primeiro patch de correção, ou seja, o 9.5.1 para que as pessoas se sintam mais confiantes em migrar.
- Algumas empresas só migram versões com mais de um ano de existência. Com o Oracle, é comum pularem as versões .1, como o 9.1, 10.1, 11.1 e atualmente o 12.1 . Isso não é à toa, parece que as versões, .2 são muito mais estáveis. As versões 10.2 e 11.2 por exemplo, eram visivelmente mais maduras que suas antecessoras.
- Um ponto fora da curva que deve ser notado: se uma nova funcionalidade fizer muita diferença para o seu negócio. Você pode optar por migrar mais rápido para uma nova versão para obter uma vantagem importante. Neste caso, é preciso ter uma equipe experiente e que tenha noção dos riscos envolvidos. Claro que se você tiver suporte adequado, isso se torna menos doloroso e você será capaz de reagir mais rapidamente, caso contrário, será que vale o risco?
O artigo Posso usar o PostgreSQL 9.5 em produção hoje? apareceu primeiro em Savepoint.
PostgreSQL 9.5 lançado!
7 de Janeiro de 2016, 17:36 - sem comentários aindaEste artigo foi escrito por telles
Mais uma aguardada versão do postgres foi lançada hoje, 07/01/2016. A versão traz muitas novidades interessantes, 3 delas foram desenvolvidas pelo nosso consultor da Timbira, Sr. Fabrizio de Royes Mello. Veja no release notes, a lista completa das novas funcionalidades do 9.5.
- Para comemorar o lançamento da 9.5 lançamos uma pesquisa para as pessoas dizerem quais as novas funcionalidades do PostgreSQL que elas gostaram mais.
- Divulgaremos o resultado no dia 20/01 no nosso primeiro Programa de Índio do ano, falando sobre o PostgreSQL 9.5, a próxima versão 9.6 e o que mais vem pela frente.
O artigo PostgreSQL 9.5 lançado! apareceu primeiro em Savepoint.