Há diversas - pequenas e fáceis - dicas esquecidas para ajudar a otimizar o uso de índices. Aqui estão duas normalmente mencionadas.

Use o tipo de dados correto!
Tenha certeza que seus tipos de dados são equivalentes para se certificar de que seus índices serão usados. Use conversão implícita de tipo de dados se necessário. (Edição #36.2)

Quando o índice é de um tipo bigint, por exemplo, tenha certeza que a expressão contenha um valor do tipo bigint para comparar. E lembre-se, números sem marcações complementares são assumidos como do tipo inteiro (int4).

	bigintcol = 5 --> pode não usar o índice.
	bigintcol = 5::bigint --> este provavelmente irá usar o índice.

Use uma expressão de índice funcional correta!
Se você possui uma função de índice como what_year(mytimestamp) e então, você faz uma consulta usando

	2003 = mytimestamp

	2003 = what_year(mytimestamp)

Colaboradores: elein em varlena.com Francois Suter dba em paragraf.ch Martijn van Oosterhout kleptog em svana.org

Quando você está ajustando consultas, é importante saber que os tipos de dados podem ser convertidos (cast) para determinados tipos de dados e em determinados contextos. Veja o item anterior nesta edição #36.1 Há três níveis de possíveis conversões entre tipos.

• Explícito -- Somente converte Explicitamente assinalados com :: ou com sintaxe de função
• Designação -- É como a corversão Explícita adicionando Implicitamente a conversão por designações e criação de listas de destino
• Implícito -- É como a conversão por Designação adicionando Implicitamente a conversão de tipos para expressões.

Explícito significa que você deve forçar o sistema a fazer a conversão de tipo para você. Implícito significa que o sistema irá fazer a conversão de tipo para você, dependendo do contexto.

Para encontrar quais tipos podem ser covertidos de um para outro e como fazê-lo, voce pode consultar a tabela pg_cast do catálogo do sistema. A visão (view) abaixo fará isto para você:

   create view showcasts as
   select t.typname as source, t1.typname as target, p.proname as function, 
   (select case when c.castcontext = 'e'
      then 'Must use Explicit Cast'
      else ( select case when c.castcontext = 'i'
            then 'Implicit cast for expressions and assignments'
            else 'Implicit cast only for assignments'
            end)
      end ) as casttype
   from pg_cast c, pg_type t, pg_type t1, pg_proc p
   where c.castsource = t.oid and
      c.casttarget = t1.oid and
      c.castfunc = p.oid;

Colaboradores: elein em varlena.com

LinuxTag 2003, 10. a 13. de Jullho na Alemanha

Esta é a terceira LinuxTag que eu assisto. A primeira coisa que eu notei quando chegamos ao pavilhão de exibição foi o grande número de pessoas aguardando na entrada para pegar seus convites. Isto foi algo surpreendente em comparação com todos enormes eventos de TI e exibições na Alemanha que atrairam menos expositores e menos visitantes que nos anos anteriores. O movimento de Código Aberto parece seguir por outro caminho. O grupo da publicação LinuxTag declarou que havia por volta de 40% mais visitantes do que o ano passado.

O PostgreSQL foi mostrado na exibição feita pela Credativ, a empresa de Michael Meskes, assim como nos anos anteriores. O PostgreSQL estava sendo apresentado no estande deles. Ele tinha um cartaz com o elefante azul na parede.

O MySQL tinha seu próprio estande (como nos últimos dois anos). No estande que estava a marca MySQL, haviam pessoas com camisetas do MySQL e desenvolvedores MySQL. E houve mais palestras e workshops. A comunidade MySQL na Alemanha é forte e, a comunidade PostgreSQL não é.

Nós tentamos encontrar algumas pessoas do PostgreSQL para o estande do PHP, mas infelizmente ninguém respondeu. O plano era 'PHP e amigos' mas acabou sendo 'PHP+MySQL, PHP+Apache e assim por diante. O pessoal do PHP não queria mencionar o PostgreSQL porque não havia ninguém lá que pudesse responder às dúvidas dos visitantes.

Bruce Momjian apresentou o PostgreSQL no congresso aberto. Ele falou sobre PostgreSQL: Passado, Presente e Futuro. Ele deu um breve visão sobre a história do PostgreSQL e então, mudou para as diferenças entre códigos fechados e códigos abertos. Ele explicou o processo de desenvolvimento e mostrou que o PostgreSQL está produzindo versões 'baseados em características' ao invés de versões 'baseados em tempo', que resultam em melhoramentos para a qualidade do software. Ele então deu alguns exemplos de áreas em que o PostgreSQL é usado e, ele fez com que nós entendêssemos que o PostgreSQL pode ser usado em qualquer aplicação ;-)

Embora houvessem três palestras interessantes ao mesmo tempo, por volta de 120 pessoas estavam prestando atenção à sua palestra e, em seguida, Bruce teve que responder muitas perguntas.

A palestra de Jon 'Maddog' Hall estava intitulada como "Coisas que eles Ainda não entendem". Ele falou sobre as diferenças entre o desenvolvimento de código aberto e de código proprietário. Ele mostrou as vantagens do desenvolvimento de código aberto e as dificuldades em conseguir convencer gerentes a usar esse tipo de produto. Por exemplo, como responder a eles dúvidas sobre suporte.

Ken Coar, Apache Software Foundation e a IBM, falaram sobre o Posicionamento Comercial do Código Aberto. ele explicou como a IBM e a Apache estão cooperando e como a cooperação chegou neste ponto.

Colaboradores: Cornelia Boenigk poppcorn em cornelia-boenigk.de

Quando usamos um UPDATE...FROM, não é necessário (nem mesmo recomendado) adicionar a tabela de destino na cláusula FROM. A tabela de destino já faz parte implicitamente da cláusula FROM de qualquer maneira; suas colunas estão disponíveis para a cláusula WHERE (embora você deva referenciá-la usando o nome inteiro da tabela e não um apelido). Adicionando a tabela de destino explicitamente na cláusula FROM, dará à você uma outra "cópia" da tabela com a qual os resultados são construídos. Considere o seguinte caso:

	UPDATE prod.t_results SET expdate=e.termdate 
	FROM work.termdate e, prod.t_results r 
	WHERE e.docid=r.docid;

	UPDATE prod.t_results SET expdate=(...alguma coisa...);

	(SELECT e.termdate
	 FROM work.termdate e, prod.t_results r
	 WHERE e.docid = r.docid);

O escopo da cláusula WHERE é alterado quando você remove a cópia extra da tabela prod.t_results e referencia a tabela que você está atualizando diretamente.

	UPDATE prod.t_results SET expdate=e.termdate
	FROM work.termdate e
	WHERE prod.t_results.docid = e.docid;

	update prod.t_results set expdata=(...alguma coisa...)

	select e.termdate from work.termdate
	where prod.t_results.docid=e.docid

Colaboradores: Maksim Likharev mlikharev em aurigin.com, Stephan Szabo sszabo em megazone.bigpanda.com

Esta é uma pequena e bela visão (view) a qual listará os gatilhos no seu banco de dados. Esta é uma adição muito útil para suas ferramentas no pg_catalog por que não há no psql um utilitário que mostre os gatilhos individualmente. Gatilhos são geralmente mostrados conjuntamente com as tabelas a que estão anexados.

	create view showtriggers as
	select trg.tgname as trigger_name , tbl.relname as table_name,
	      p.proname as function_name,
	       case trg.tgtype & cast(2 as int2)
	         when 0 then 'AFTER'
	         else 'BEFORE'
	       end as trigger_type,
	       case trg.tgtype & cast(28 as int2)
	         when 16 then 'UPDATE'
	         when 8 then 'DELETE'
	         when 4 then 'INSERT'
	         when 20 then 'INSERT, UPDATE'
	         when 28 then 'INSERT, UPDATE, DELETE'
	         when 24 then 'UPDATE, DELETE'
	         when 12 then 'INSERT, DELETE'
	       end as trigger_event
	from pg_trigger trg, pg_class tbl, pg_proc p
	where trg.tgrelid = tbl.oid and trg.tgfoid = p.oid;

Colaboradores: Holger Marzen holger em marzen.de, Thomas Kellerer spam_eater em gmx.net