Ir para o conteúdo
ou

Software livre Brasil

Tela cheia
 Feed RSS

SAVEPOINT

27 de Maio de 2009, 0:00 , por Software Livre Brasil - | Ninguém está seguindo este artigo ainda.

PostgreSQL fillfactor

26 de Janeiro de 2016, 20:57, por Savepoint - 0sem comentários ainda

Este 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, por Savepoint - 0sem comentários ainda

Este 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 chkpasspasswordcheckpgcrypto.
  • 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, por Savepoint - 0sem comentários ainda

Este 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, por Savepoint - 0sem comentários ainda

Este 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, por Savepoint - 0sem comentários ainda

Este 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.