Versão Alfa do PostgreSQL 9.0 Lançada!

A versão de desenvolvimento ALFA do PostgreSQL 9.0 está disponível para downloads e testes.

Na verdade, é a quarta versão alfa, uma vez que três versões anteriores haviam sido lançadas como sendo para o PostgreSQL 8.5.

Faça o download aqui!

Veja as notas de lançamento com os avanços desta versão aqui!

Select - Cláusulas FOR UPDATE, FOR SHARE e NOWAIT

Influenciar nos mecanismos de bloqueio do banco de dados nem sempre é um processo intuitivo. No entanto, pode ser bastante útil para garantia da confiabilidade de resultados e para ajustes de desempenho.

A existência de bloqueios sobre os dados acessados durante o acesso concorrente não pode ser ignorada em sistemas com grande número de transações concorrentes mesmo no Postgres que utiliza o protocolo de bloqueios multiversão (MVCC - MultiVersion Concurrency Control). 

O PostgreSQL oferece algumas cláusulas relativamente simples que permitem este tipo de controle no caso de consultas no banco de dados: FOR UPDATE, FOR SHARE e NOWAIT.

O uso de consultas com a cláusula FOR UPDATE obriga o servidor a bloquear os registros consultados para leitura e escrita durante o transcorrer da transação. Desta forma se garante que o que está sendo visualizado corresponde ao que está armazenado no banco de dados.

Por sua vez, a cláusula FOR SHARE efetua bloqueio de escrita, mas permite que leituras sejam feitas aos dados consultados.

Em resumo, a cláusula FOR UPDATE restringe os acessos aos dados consultados, enquanto que a FOR SHARE explicitamente autoriza acessos de leitura aos dados consultados. O tipo de transação é que determina se e quando utilizar estas cláusulas.

É importante salientar que ambas as cláusulas se referem apenas os dados que são recuperados na consulta.

Adicionalmente, a cláusula NOWAIT pode ser utilizada tanto com FOR UPDATE quanto com FOR SHARE, e força a ocorrência de erro caso o servidor tenha de esperar para a obtenção de bloqueios nos dados consultados. Desta forma, sacrifica-se a transação para que não se perca tempo na fila de espera por bloqueios.

As cláusulas UNION, INTERSECT e EXCEPT até o momento não são compatíveis com FOR UPDATE e FOR SHARE.

Para os próximos exemplo, serão utilizadas as seguintes tabelas:

CREATE TABLE pai (codpai integer,nomepai varchar(50));
CREATE TABLE filho (codpai integer,codfilho integer,nomefilho varchar(50));

Exemplos:

1 - Sintaxe simples com FOR UPDATE.

SELECT * FROM pai FOR UPDATE;

2 - Sintaxe simples com FOR SHARE.

EXPLAIN SELECT * FROM pai FOR SHARE;

3 - Uso de FOR SHARE em consulta com junção.

SELECT *
FROM pai p, filho f
WHERE p.codpai = f.codpai
FOR SHARE;

4 - Uso de NOWAIT.

SELECT * FROM pai FOR UPDATE NOWAIT;

5 - Uso de FOR UPDATE em transação de atualização.

BEGIN;
SELECT * FROM pai FOR UPDATE;
UPDATE pai SET nomepai = nomepai ' Father';
COMMIT;

Algoritmos: Caixa de Banco Simulado no PostgreSQL

Ao retirar dinheiro de um caixa eletrônico, solicitamos uma quantia e o caixa decide quantas notas de cada tipo disponível nós receberemos. O algoritmo que faz esta decisão é relativamente simples.

Abaixo coloco uma função que recebe uma solicitação de dinheiro e calcula quantas notas de 100, 50, 10, 5 e 1 serão retornadas ao solicitante:

--Retornando notas do caixa eletrônico
--Notas de 1, 5, 10, 50 e 100
CREATE OR REPLACE FUNCTION caixa_elet (pvalor integer) RETURNS text AS $$
DECLARE
sretorno text;
qnota1 integer;
qnota5 integer;
qnota10 integer;
qnota50 integer;
qnota100 integer;
BEGIN
sretorno := '';
qnota100 := (pvalor - (pvalor % 100))/100;
qnota50 := ((pvalor % 100) - (pvalor % 50)) /50;
qnota10 := ((pvalor % 50) - (pvalor % 10)) /10;
qnota5 := ((pvalor % 10) - (pvalor % 5)) /5;
qnota1 := ((pvalor % 5) - (pvalor % 1)) /1;
sretorno := 'Total: ' || pvalor || chr(10) || 'Notas de 100:' || qnota100 || chr(10) || 'Notas de 50:' || qnota50 || chr(10) || 'Notas de 10:' || qnota10 || chr(10) || 'Notas de 5:' || qnota5 || chr(10) || 'Notas de 1:' || qnota1;
RETURN sretorno; -- Retorna as linhas
END;
$$ LANGUAGE plpgsql;

Chamada da função e resultado apresentado:

SELECT caixa_elet(1078);

"Total: 1078
Notas de 100:10
Notas de 50:1
Notas de 10:2
Notas de 5:1
Notas de 1:3"

SELECT caixa_elet(2189);

"Total: 2189
Notas de 100:21
Notas de 50:1
Notas de 10:3
Notas de 5:1
Notas de 1:4"

Agora, gostaria de fazer algumas perguntas para os programadores de plantão:
- O código da função caixa_elet está correto?
- O código da função caixa_elet pode ser melhorado de que formas?
- Que alterações seriam necessárias para acrescentar notas de 20?

Aguardo suas contribuições nos comentários!

8.5 sai de cena antes de ser lançado: nova versão do Postgres será a 9.0!

O anúncio não é oficial, mas a versão 8.5 terá sua numeração alterada para 9.0. Os testes e o desenvolvimento continuam normalmente.

As razões envolvendo a mudança compreendem o aumento das funcionalidades da nova versão e da abrangência das alterações no código, o grande tempo desde a primeira versão 8.* e um benefício em termos de marketing, pela insinuação de uma mudança mais substancial refletida na alteração de 8.4 para 9.0.

Você concorda com essa atitude?

PostgreSQL e JDBC: Ótimo exemplo de código!

A utilização de linguagem java nas aplicações com PostgreSQL depende de um middleware para o acesso aos dados. O JDBC oferece conexões com segurança e confiabilidade. Mas como implementar estes acessos?

O link abaixo apresenta um ótimo exemplo introdutório de código java para acesso ao Postgres via JDBC. Confira aqui.

Onde esse elefante está? O que nos diz o google insights sobre o ano de 2009?

As pesquisas na internet dizem muito sobre a aceitação de produtos, serviços, candidatos a cargos eletivos e sobre o uso de programas e sistemas. Com o PostgreSQL não é diferente. Fiz uma breve pesquisa sobre o ano de 2009 no google insights e os resultados compartilho neste post. O levantamento do ano passado está aqui.

As imagens capturadas e os dados foram todos coletados dia 18/12/2009.

- O ano de 2009 foi relativamente estável. Houve uma queda nas buscas com a festas de fim de ano e um aumento nas pesquisas durante o lançamento da nova versão 8.4, em meados de abril. A figura 1 mostra a evolução destas buscas no ano.


Considerando os últimos 4 anos, houve uma diminuição nas buscas. No entanto isto não significa necessariamente perda de espaço, podendo indicar também uma maior disseminação do conhecimento sobre o banco, que reduz a necessidade de pesquisas na rede.


- No mundo, Japão e Rússia crescem no ranking relativo de buscas e recuperam as primeiras posições perdidas em 2008 para Cuba e China.


- No mundo ganha destaque a busca "PostgreSQL MySQL", indício de que o PostgreSQL não é considerado uma alternativa tão natural ao Oracle ou ao Sql Server, mas uma boa opção em relação ao MySQL (Esta é apenas uma suposição que carece de mais comprovação!).

- No Brasil destaco as buscas "PostgreSQL Windows" e "PostgreSQL Linux". A pontuação destas buscas mostra que a compatibilidae com vários sistemas operacionais é um importante fator para os projetos de software nacionais.

- O Brasil continua em uma posição intermediária. Na América do Sul o destaque fica para a Bolívia, que ocupa a quarta posição entre os 10 maiores índices de busca pelo PostgreSQL no Google.

- Dentre os estados brasileiros, Distrito Federal e Ceará ocupam as duas primeiras posições. Santa Catarina, Paraná e Rio Grande do Sul estão nas três posições subsequentes, o que mostra a força do PostgreSQL na Região Sul.


Não recomendo que estes dados sejam utilizados para a tomada de decisões. São informações retrospectivas sujeitas a erros estatísticos! 2009 está consumado. Agora é trabalhar pelo 2010!

GreenSQL: O Rinoceronte Amigo do Elefante!

Segurança nunca é demais e cautela e caldo de galinha não fazem mal a ninguém! No caso do PostgreSQL não é diferente, e qualquer atualização de segurança é sempre recomendada.

O GreenSQL é um firewall de código aberto que visa proteger bases de dados de ataques tipo "SQL Injection", verificando os comandos submetidos ao banco, restringindo comandos de administrador para criação e destruição de tabelas e outros objetos e impedindo a submissão de códigos maliciosos. Seu símbolo é o do Rinoceronte.



A versão mais recente agregou o suporte ao PostgreSQL ao do MySQL já existente. Espera-se que o Rinoceronte possa agir como guarda costas do elefante a partir deste lançamento! Abaixo, uma imagem da arquitetura do GreenSQL.

A licença é GPL. Teste e me diga o que achou!

Enquete aponta que PostgreSQL Crescerá com a Compra do MySQL

A compra recente da Sun pela Oracle, incluindo o banco MySQL começa a trazer mudanças no mercado. Segundo enquete realizada pelo "The 451 Group", há uma tendência de redução do market share do MySQL em detrimento do PostgreSQL e do novo banco de dados MariaDB, que seria um fork livre do MySQL com um processamento de consultas novo e bastante promissor.

Este autor acha que há espaço para todos, e acredita no crescimento do PostgreSQL independentemente do apresentado pelas demais alternativas. Aproveita para lembrar que enquetes revelam apenas intenções, e que o mercado pode tomar outra direção.

O que você acha? O que tem acontecido na sua empresa?

O artigo original pode ser obtido aqui.

O Comando Table

O comando TABLE é muito pouco conhecido entre os usuário do Postgres, no entanto isto não chega a ser um problema. É um comando que funciona mais como uma curiosidade do que como uma funcionalidade real. Sua função principal é economizar digitação de consultas relativas a todos os dados de uma tabela.

Consultas com a sintaxe abaixo, por exemplo:

SELECT * FROM tabela;

Poderiam ser simplificadas para:

TABLE tabela;

O ganho é apenas de tempo de digitação ou de simplificação. O plano de execução é o mesmo.

O comando TABLE pode ser utilizado no lugar de "SELECT * FROM" de diversas maneiras diferentes:

Exemplo 1:

TABLE ADDRESS; --Recupera todas as colunas e linhas da tabela ADDRESS

Exemplo 2:

TABLE ADDRESS ORDER BY postal_code; --Classifica e recupera todas as colunas e linhas da tabela ADDRESS

Exemplo 3:

TABLE ADDRESS ORDER BY postal_code DESC; --Classifica de modo decrescente e recupera todas as colunas e linhas da tabela ADDRESS

Exemplo 4:

SELECT * FROM ADDRESS
UNION ALL
TABLE ADDRESS; --Uso de TABLE com UNION

Tutorial de PostgreSQL e Hibernate

Bom tutorial introdutório de PostgreSQL com Hibernate aqui.
O autor autoriza o uso mas não a redistribuição!

PostgreSQL 8.5 - Versão Alfa

Como desenvolver uma ferramenta altamente poderosa? Certamente um dos passos é a atualização e renovação constante. No caso do PostgreSQL, antes que uma versão seja lançada, existe um planejamento das futuras implementações. Desta forma, sempre existe um horizonte de crescimento.

A versão 8.4 está sendo atalizada com correções e ajustes nas fuincionalidades, mas em paralelo, a nova versão 8.5 está em desenvolvimento, estando em sua versão alfa. O site para download se encontra aqui. A versão alpa 2 está disponível para download e são disponibilizadas informações sobre as novas funcionalidades para a versão 8.5!

Monitoração de Comandos com PG_STAT_STATEMENTS

Na versão 8.4, foram acrescentados novos recursos de monitoramento de banco que podem ser bastante úteis para se identificar que consultas têm consumido mais tempo, retornam mais dados e quais são executadas com maior freqüência. A pg_stat_statements é uma biblioteca que monitora e coleta estas informações para o usuário.

Para monitorar o que acontece no sgbd, é necessário manter em memória uma rotina que realize essa atividade. Para colocar esta rotina em execução, deve ser alterado o arquivo de configuração, mais precisamente a variável “shared_preload_libraries”, e reiniciado o servidor. Acrescente no arquivo de configuração postgresql.conf a linha abaixo e reinicie o serviço do banco:

shared_preload_libraries = '$libdir/pg_stat_statements'

Para visualizar se a biblioteca realmente foi colocada na memória pode ser usado o comando show:

Show shared_preload_libraries

Execute algumas consultas para que o sgbd armazene valores monitorados. Serão guardados os códigos dos comandos, o número de vezes em que os mesmos foram executados e os tempos de execução.

O próximo passo é executar o script do arquivo “contrib/pg_stat_statements/pg_stat_statements.sql” que se encontra na pasta de contribs para criar uma visão que mostrará os dados monitorados chamada pg_stat_statements. Abaixo, coloco a consulta padrão aos dados de monitoramento e alguns exemplos adicionais de consultas por número de chamadas ao comando, pelo tempo total e pelo número de linhas retornado.

1 - Consulta padrão

select * from pg_stat_statements;

2 - Consultas ordenadas pelo número de chamadas

select * from pg_stat_statements order by calls desc;

3 - Consultas ordenadas pelo tempo total utilizado

select * from pg_stat_statements order by total_time desc;

4 - Consultas ordenadas pelo número de linhas retornado

select * from pg_stat_statements order by rows desc;

Caso a quantidade de dados retornados seja muito grande, utilize a função pg_stat_statements_reset para limpar os dados coletados:

1 – Limpando dados coletados

select pg_stat_statements_reset();