segunda-feira, 8 de março de 2010

PostgreSQL 9.0: Quais são as novidades? A visão das "funcionalidades da semana" - Parte 1!!!

O PostgreSQL está em sua quarta versão alfa, e começam a aparecer indicações das novas funcionalidades e alterações que foram introduzidas. O informe semanal "PostgreSQL Weekly News", organizado por David Fetter apresenta uma seção chamada "Feature of the Week", ou funcionalidade da semana, descrevendo uma alteração em desenvolvimento. Os informes originais podem ser consultados aqui.

Abaixo listo as últimas funcionalidades citadas, agregando algum comentário quando pertinente:

28/03/2010 - Implementação do conceito de blocos anônimos de código (anonymous code blocks) através do comando DO nas linguagens PL/pgsql, PL/Perl, e PL/LOLCODE.

Estes blocos compreendem comandos que podem ser executados em um bloco de código sem um nome, utilizando as poderosas linguagens procedurais do PostgreSQL. Desta forma podem ser executados blocos de código sem que se precise criar funções dentro do banco. Parece uma ótima forma de se criar scripts.

O exemplo abaixo eu peguei aqui:

DO $$DECLARE r record;
BEGIN
FOR r IN SELECT table_schema, table_name FROM information_schema.tables
WHERE table_type = 'VIEW' AND table_schema = 'public'
LOOP
EXECUTE 'GRANT ALL ON ' || quote_ident(r.table_schema) || '.' || quote_ident(r.table_name) || ' TO webuser';
END LOOP;
END$$;

21/03/2010 - Campos do tipo Hstore não tem mais o limite de 64kB para o limite de chaves e suportam árvore B e classes de operadores hash, permitindo GROUP BY, DISTINCT, etc.

Obs: Você sabe por acaso o que é HSTORE? Eu também não sabia, mas é um módulo que implementa um tipo de dados chamado HSTORE que agrega ao mesmo tempo uma chave e um valor, ambos strings. Este novo tipo de dado é útil para uma série de cenários. Mais informações podem ser obtidas aqui.

14/03/2010 - Em PL/pgsql, o comando MOVE agora funciona de forma compreensível com Cursores.

Obs: Não deu para entender o problema que havia antes, mas este comando reposiciona o cursor sem recuperar dados (NEXT, PRIOR, FIRST, LAST, ABSOLUTE count, RELATIVE count, FORWARD, ou BACKWARD).

07/03/2010 - A saída do EXPLAIN pode ser formatada como XML, JSON, YAML e o mecanismo de análise está muito mais simples. O formato tradicional de texto ainda é o formato padrão.

Obs: Os novos formatos permitem a definição de relatórios e ferramentas de análise dos resultados do comando Explain, facilitando a otimização de consultas.

28/02/2010 - A suíte pgbench agora é multi-threaded, o que lhe permite tirar partido de múltiplos núcleos de CPU.

Obs: O pgbench é um utilitário que faz o benchmark de desempenho do servidor. Pode ser utilizada para testes de estresse, carga e performance. O uso de múltiplas threads faz com que os resultados sejam mais confiáveis e obtidos em menor tempo.

21/02/2010 - Agora você pode controlar o comportamento de valores distintos para cada coluna com ALTER TABLE ALTER COLUMN ... ... SET (parâmetro = valor ,...) onde parâmetro pode ser uma das n_distinct e n_distinct_inherited. Valores positivos são assumidos como sendo o número de valores distintos aceitos, 0 diz que o planejador da consulta deve utilizar os resultados do comando ANALYZE, e os números negativos (que devem estar entre -1 e 0) fazem com que o planejador estime o número de valores distintos como o número de linhas multiplicado pelo valor absoluto do número.

Obs: Funcionalidade de performance, para consultas específicas.

14/02/2010 - Violações de restrição de unicidade de valor agora geram mensagens de erro mais detalhadas.

Obs: Agora fica mais fácil encontrar a causa de exceções de valores repetidos e como resolvê-las.

31/01/2010 - A checagem de constraints de não repetição de valores pode agora ser adiada até a hora do commit.

Obs: Funcionalidade de performance, para consultas específicas.

24/01/2010 - A sintaxe DROP IF EXISTS agora trabalha em colunas e restrições.

Obs: Sintaxe interessante para os desenvolvedores de ferramentas de banco de dados.

17/01/2010 - O Vacuum full foi alterado para gerar novos arquivos para tabelas e índices por padrão. Esta implementação é baseada no antigo comando CLUSTER e mais eficiente e efetiva. A funcionalidade antiga do VACUUM FULL ainda pode ser acessada através do comando VACUUM FULL INPLACE, mas será incompatível com o Hot Standby.

Obs: O Vacuum Full Implace só parece ser vantajoso para sistemas com pouco espaço em disco. A nova Implementação promete ganho de tempo nas manutenções de banco.

10/01/2010 - Agora você pode armazenar em log o estado de consultas SQL, erros, etc, usando "%e" na sua log_line_prefix.

03/01/2010 - No psql o uso de "\d" agora mostra quantas tabelas herdadas uma tabela-mãe tem, e "\d+" lista os nomes das tabelas herdadas.

Obs: Alteração de pouco impacto para quem não utiliza recursos objeto-relacionais.

27/12/2009 - Hot Standby. Após 1,5 anos de desenvolvimento, você pode finalmente executar consultas somente leitura PITR contra os escravos. Graças ao Simon Riggs, Heikki Linnakangas, qualquer muitos outros esforços incessantes.

Obs: O melhor uso de hardware promete ganho de desempenho e redução de custos para grandes sistemas escaláveis e resistentes a falhas. Esta é uma das funcionalidaes que merecerá bastante atenção dos DBAs.

20/12/2009 - Cláusulas WHEN sobre Triggers. Na versão 8.5 Alpha3 você será capaz de criar triggers com uma cláusula WHEN para que as mesmas executem apenas se os valores ou condições específicas ocorrerem. Graças Itagaki Takahiro e a equipe da NTT.

Obs: Esta alteração permite triggers mais específicas com menos validações internas, possivelmente impactando positivamente seu desempenho.

13/12/2009 - Constraints de exclusão (por Jeff Davis) permitem que você especifique como únicos "dados" que abranjam um intervalo, como uma área geométrica, um período de tempo, ou um array.

Obs: Função importante para quem trabalha com lógicas de negócios no banco de dados.

Abaixo, a redação oficial da coluna:

07/03/2010 - EXPLAIN output can be formatted as XML, JSON, and YAML, making machine parsing much simpler. The traditional text format is still the default format.

28/02/2010 - The pgbench suite is now multi-threaded, allowing you to take advantage of multiple CPU cores.

21/02/2010 - You can now control the behavior of distinct values per column using ALTER TABLE...ALTER COLUMN...SET (parameter=value,...) where parameter can be one of n_distinct and n_distinct_inherited. Positive numbers are assumed to be the number of distinct values, 0 tells the planner to use the results from ANALYZE, and negative numbers (which should be between -1 and 0, cause the planner to estimate the number of distinct values as the estimated number of rows multiplied by the absolute value of the number.

14/02/2010 - Uniqueness violations now raise more detailed error messages.

31/01/2010 - Uniqueness constraints can now be deferred until commit time.

24/01/2010 - The DROP IF EXISTS syntax now works on columns and constraints.

17/01/2010 - VACUUM FULL has been changed to now generate all-new files for the vacuumed table and indexes. This is based on the old CLUSTER command, and is both more efficient and more effective. The old functionality of VACUUM FULL can still be accessed via VACUUM FULL INPLACE, but will be incompatible with Hot Standby.

10/01/2010 - You can now log SQL state for queries, errors, etc., using %e in your log_line_prefix.

03/01/2010 - In psql, \d now shows how many inherited tables a parent has, and \d+ lists them.

27/12/2009 - Hot Standby. After 1.5 years of development, you can at last run read-only queries against PITR slaves. Thanks to Simon Riggs, Heikki Linnakangas, any many others for unceasing efforts.

20/12/2009 - WHEN clauses on Triggers. In 8.5Alpha3, you will be able to create triggers with a WHEN clause so that they will only execute if specific values or conditions occur. Thanks Itagaki Takahiro and the NTT team.

13/12/2009 - Exclusion Constraints (by Jeff Davis) allow you to specify as "unique" data which covers a range, such as a geometric area, a period of time, or an array.

O que acharam destas novas funcionalidades?

Elas impactarão o seu trabalho atual?

4 comentários:

Leo disse...

Olá Claudino, estou passando por aqui para apreciar seu blog e parabenizar o excelente trabalho que você vem exercendo para a comunidade com seus artigos sobre PostgreSQL.

Um abraço!

-Leo

Anônimo disse...

Na última vez que ví o PostgreSQl, ele não tinha tratamento de "accent insensitive" e "case insensitive" no nível do existente em outros SGBDs (SQLServer, Firebird).

Isto foi contemplado nesta versão ?(tornar o conteúdo "JOSÉ" igual a "jose" para qualquer tipo de comparação em qualquer tipo de operador (like, =, in, containing))

cbleopoldino disse...

Que eu saiba, não foi feito nada ainda para a questão da acentuação.

Anônimo disse...

Pessoal, vi a última pergunta sobre acentuação e existe uma função que eu uso que faz isto que é a TO_ASCII que pode ser utilizada da seguinte forma:


SELECT * FROM (SELECT 'José' AS nome UNION SELECT 'João' AS nome) clientes WHERE UPPER(TO_ASCII(nome,'LATIN1')) = TO_ASCII('JOSÉ','LATIN1')

OU

SELECT * FROM (SELECT 'José' AS nome UNION SELECT 'João' AS nome) clientes WHERE TO_ASCII(nome,'LATIN1') ILIKE TO_ASCII('JOSÉ','LATIN1')

Espero ter contribuído com algo apesar da data da ultima mensagem.