O que vem por aí no PostgreSQL 8.2
“A notícia está um pouco atrasada mas em agosto a versão 8.2 foi congelada, novas funções ou características não podem ser adicionadas. Em setembro ou outubro deve sair o primeiro beta, dentre as novidades estão:
- Standby databases: Melhoria no PITR (Point In Time Recovery) - essa parte foi bastante modificada com inclusão de índices que não estavam na 8.1 e suporte melhorado para trabalhar com Sevidores Stand By e Cluster.
- Construção Online de Índices (Online Index Build) : uso de aplicações OLTP (Online Transacition Processing) beneficiaram bastante dessa função, pois agora será possível criar ou reindexar os índices numa atualização.
- Stored Procedure Debugging: Com uma nova API será possível criar ferramentas interativas de debugging para stored procedures, com uma interface gráfica para PL/PgSQL ainda em Beta.
- Update Views: Para fazer atualizações à partir de Views é uma das coisas mais trabalhosas já que não pode atualizar diretamente, no 8.2 isso já está resolvido. - Melhora na performance do Outer Join: Execução de consultas com Outer Join estão 300% mais rápidas.
- On-disk Bitmap Indexes: Incluso Índices bitmap compactado sobre colunas de baixa cardinais de tabelas muito grandes que pode chegar à 50 vezes menores comparado aos índices B-tree, habilitando indexação rápida de muito terabytes de banco de dados.”
Enviado por Fernando Ike (fernando·ikeΘgmail·com) - referência.
(postado por Augusto Campos)
Comentários dos leitores
Comentário de Carlos Romel
13/09/06 15:21 - usuário registrado #935
otimização de {{right,left}, outer, inner} joins: Olá.
Em um projeto que participei integrando o PostgreSQL 7.x, havia uma consulta que, quando usava a sintaxe:
era sensivelmente mais lenta que:
O tempo passou, mas ficaria muito feliz em saber que o algorítmo das junções foi melhorado para casos reais.
Em um projeto que participei integrando o PostgreSQL 7.x, havia uma consulta que, quando usava a sintaxe:
--- 8< ---
select a.coluna1,
b.coluna2
from tabela1 a
inner join tabela 2 b
on a.i1 = b.i1
--- >8 ---
era sensivelmente mais lenta que:
--- 8< ---
select a.coluna1,
b.coluna2
from tabela1 a,
tabela2 b
where a.i1 = b.i1
--- >8 ---
O tempo passou, mas ficaria muito feliz em saber que o algorítmo das junções foi melhorado para casos reais.
Comentário de alepaes
13/09/06 16:43 - usuário registrado #99
Depende da versão: Se for menor ou igual a 7.3, havia realmente alguns problemas no parser.
A versão 7.4 trouxe inúmeras melhorias nesse quesito.
Se você usar o 8.1 então, vai se surpreender... :)
Alexandre de Arruda Paes
A versão 7.4 trouxe inúmeras melhorias nesse quesito.
Se você usar o 8.1 então, vai se surpreender... :)
Alexandre de Arruda Paes
Comentário de Walter Cruz
14/09/06 12:17 - usuário registrado #3199
Otimizador: Oi Carlos.
A seguinte consulta:
Me retorna esse plano:
E essa outra aqui:
retorna o mesmo plano:
Ou seja: atualmente, o otimizador considera as duas equivalentes, como de fato, é.
E o 8.2 vai fazer otimizações ainda mais agressivas em outer joins ...
[]'s
- Walter
A seguinte consulta:
select m.nomemunicipio,
e.siglaestado
from tab_municipios m,
tab_estado e
where m.idestado = e.idestado
Me retorna esse plano:
Hash Join (cost=1.34..180.44 rows=5564 width=21) (actual time=0.193..32.012 rows=5564 loops=1)
Hash Cond: ("outer".idestado = "inner".idestado)
-> Seq Scan on tab_municipios m (cost=0.00..95.64 rows=5564 width=19) (actual time=0.012..11.109 rows=5564 loops=1)
-> Hash (cost=1.27..1.27 rows=27 width=10) (actual time=0.161..0.161 rows=27 loops=1)
-> Seq Scan on tab_estado e (cost=0.00..1.27 rows=27 width=10) (actual time=0.006..0.084 rows=27 loops=1)
Total runtime: 40.013 ms
E essa outra aqui:
select m.nomemunicipio,
e.siglaestado
from tab_municipios m
inner join tab_estado e
on m.idestado = e.idestado
retorna o mesmo plano:
Hash Join (cost=1.34..180.44 rows=5564 width=21) (actual time=0.207..32.529 rows=5564 loops=1)
Hash Cond: ("outer".idestado = "inner".idestado)
-> Seq Scan on tab_municipios m (cost=0.00..95.64 rows=5564 width=19) (actual time=0.011..11.334 rows=5564 loops=1)
-> Hash (cost=1.27..1.27 rows=27 width=10) (actual time=0.170..0.170 rows=27 loops=1)
-> Seq Scan on tab_estado e (cost=0.00..1.27 rows=27 width=10) (actual time=0.007..0.089 rows=27 loops=1)
Total runtime: 40.649 ms
Ou seja: atualmente, o otimizador considera as duas equivalentes, como de fato, é.
E o 8.2 vai fazer otimizações ainda mais agressivas em outer joins ...
[]'s
- Walter
que maravilha, hein? só espero que não seja um número aleatório...
;; ((lambda (x) x) "Isto é um comentário e não será executado nunca")