As URLs para as edições individuais do General Bits estarão em mudança enquanto eu estiver fazendo uma pequena limpeza em casa. A marcação de página para 32.html, por exemplo, pode não funcionar mais. Para um acesso seguro às edições anteriores, guarde a marcação da página Archive listada abaixo

As seguintes marcações de páginas permanecerão estáveis.

Edição Corrente:	http://www.varlena.com/GeneralBits/
Archives (Arquivos):	http://www.varlena.com/GeneralBits/archive.php
TidBits:	http://www.varlena.com/GeneralBits/Tidbits/
Português:	http://www.varlena.com/GeneralBits/po.php

Editor: elein em varlena.com

O lado cliente da interface do python para a versão 7.4 foi removida da árvore regular do CVS. Agora, pode ser encontrado em

http://www.pygresql.org

Esta mudança é algo fora do usual. No passado as interfaces foram movidas para gborg.postgresql.org. No gborg, a página para o projeto PyGreSQL aponta para o endereço pygresql.org. Isto fica confuso, pois os links do CVS, erros e características continuam sendo mantidos no gborg.

Colaboradores: Bruce Momjian pgman em candle.pha.pa.us, Marc G. Fournier scrappy em hub.org, Tom Lane tgl em sss.pgh.pa.us, D'Arcy J.M. Cain darcy em PyGreSQL.org

Suponha que nós tenhamos uma tabela representando processos de tarefas como estas:

	=# \d procs
	                Table "procs"
	   Column   |         Type          | Modifiers
	 -----------+-----------------------+-----------
	  pid       | integer               | not null
	  task      | character varying(10) | not null
	  owner     | character varying(10) | not null
	  IsActive  | boolean               |

O problema é como manter a tabela atualizada com um e somente um registro na tabela com o campo IsActive ("EstáAtivo") com conteúdo VERDADEIRO (TRUE). Quando o processo é colocado ativo, ative-o, qualquer outro processo ativo é colocado como inativo.

A implementação é um gatilho que dispara quando um processo que for atualizado, ativar quaisquer atualizações da linha que foi previamente configurada para ativar como inativa. Aqui está a função e o gatilho.

	CREATE TRIGGER proc_current AFTER UPDATE OR INSERT ON procs
	FOR EACH ROW EXECUTE PROCEDURE proc_current_trigger();

	CREATE FUNCTION proc_current_trigger() RETURNS TRIGGER AS '
	BEGIN
	  IF NEW.IsActive THEN
	    UPDATE procs SET IsActive = ''f''
	    WHERE pid != NEW.pid AND IsActive = ''t'';
	  END IF;
	  RETURN NEW;
	END' LANGUAGE 'plpgsql';

Ambos os casos INSERT e UPDATE estão sendo manipulados pelo gatilho para assegurar que a integridade permaneça. Pois não há gatilho de DELETE e nenhuma ação quando um processo está configurado para inativo, é possível ter todos processos inativos.

A função verifica se a linha a inserir ou atualizar está configurada para ativa, e se estiver, desconfigura todas (deveria ser somente uma!) as outras linhas para inativo. As outras são concluidas excluindo a nova linha pelo pid na cláusula WHERE.

Colaboradores: Gary Stainburn gary.stainburn em ringways.co.uk, Dmitry Tkach dmitry em openratings.com, Richard Poole richard em ruthie.org

Liberações menores podem ser atualizadas no mesmo lugar da instalação atual. Neste caso nada precisa ser feito para a atualização do banco de dados. Somente os programas precisam ser atualizados.

Uma liberação menor é reconhecida pela mudança do 3º número, por exemplo, 7.3.4 é uma liberação menor de atualização da versão 7.3.2. Quando o segundo número muda, há geralmente alterações no banco de dados a serem feitas pela atualização. Por exemplo, atualizações foram necessárias quando passamos da versão 7.2 para a 7.3.

As liberações menores podem ser feitas de maneira rápida e fácil. Aqui estão alguns exemplos de como as pessoas podem fazer as atualizações menores. A primeira age cautelosamente e, antes de mais nada, faz uma cópia de segurança do banco de dados e move a instalação antiga para outro lugar seguro. A nova versão é criada e instalada. A nova área de dados tem o initdb executado e então, os dados da cópia de segurança são carregados.

	pgdumpall > dbbackup                  -- backup and stop
	pg_ctl stop
	mv %PGHOME% /usr/local/pgsql.old      -- move old pgsql program

	cd /usr/local/src/postgresql-7.3.2    -- installs new pgsql version
	make install

	initdb -D %PGHOME%/data               -- start and restore db.
	pg_ctl start
	psql < dbackup

	tar xvfz postgresql-7.3.4.tar.gz ; 
	cd postgresql-7.3.4
	./configure ; 
	make ; 
	pg_ctl stop ; 
	make install
	pg_ctl start

	pgdumpall > dbbackup 
	tar xvfz postgresql-7.3.4.tar.gz ; 
	cd postgresql-7.3.4
	./configure ; 
	make; 
	pg_ctl stop ; 
	make install

Note que o servidor de banco de dados deve ser parado antes de rodar make install. É claro, YMMV.

Colaboradores: jørn T Johansen btj em havleik.no, scott.marlowe scott.marlowe em ihs.com, Freddy Menjívar M. mmfreddy em hotmail.com, Paul Ramsey pramsey em refractions.net

Há um limite de 16 Terabytes para o banco de dados PostgreSQL. Isto é limitado por causa do BlockNumber ser de 32 bits, então você não pode ter uma tabela maior do que 2 ou 4 bilhões de blocos.

(A FAQ é conservadora, assume que o limite de 2 bilhões de blocos; 2G blocos * 8KB por tamanho de bloco = 16 TB. A princípio 4 bilhões devem funcionar, mas é necessário um teste mais rigoroso. Códigos antigos que usam aritmética com sinal em BlockNumber ainda podem existir. Há alguém que queira e seja capaz de testar um banco de dados de tamanho entre 16 e 32 Terabytes?)

Suponha que você tenha uma tabela com 50 campos de 20 caracteres cada. Se a tabela pode ser de 16TB, quantos registros esta tabela poderia armazenar? Vamos calcular.

• Você possui 50 campos com 20 caracteres cada.
• Cada campo deveria ser de 24 bytes, usando um inteiro de 4 bytes para o tamanho.
• Cada campo também possui 28 bytes de sobrecarga, assumindo o uso de OIDs por padrão. Sem OIDs, a sobrecarga do registro é de 23 bytes.
• O tamanho da tupla é de 50*(24+28)=1228 bytes.
• Em uma página de 8KB, você teria 6 tuplas carregadas.
• Em 16TB você pode acomodar 2GB páginas
• O número total de tuplas que você pode ter é de aproximadamente 12 bilhões.

Há referência de bancos de dados maiores do que 300GB. As pessoas normalmente possuem bancos de dados de 10GB em média. Você pode procurar nos arquivos da lista pelos casos.

O banco de dados de 4TB mencionado no FAQ pertence ao American Chemical Society (alguma coisa sobre digitalizar todos os jornais publicados por eles desde meados de 1800)

Outro banco de dados grande é o 2-micron sky survey: http://pegasus.astro.umass.edu/ que cobre quase meio bilhão de estrelas; é reportado o tamanho de 150GB quando carregado no PostgreSQL. O pessoal da UMass parecem bem satisfeitos com a performance que eles conseguiram.

Colaboradores: John Bercik bercikj em musc.edu, shridhar_daithankar em persistent.co.in, Tom Lane tgl em sss.pgh.pa.us, Jim C. Nasby jim em nasby.net, Bruce Momjian pgman em candle.pha.pa.us

Duas funções foram propostas, uma em plpgsql e a outra em plperl.

	create or replace function hex_to_int(char(2)) returns integer as '
	   declare
	      v_ret record;
	   begin
	      for v_ret in execute ''select x'''''' || $1 || ''''''::int as f'' loop 
	         return v_ret.f;
	   end loop;
	   end;
	' language 'plpgsql';

	create or replace function hex_to_int_perl(char(2)) returns integer as '
	   return hex $_[0];
	' language 'plperl';

	create table foo(f1 char(2));
	insert into foo values ('ff');
	insert into foo values ('fe');
	insert into foo values ('fd');

	select hex_to_int[_perl](f1) from foo;
	 hex_to_int
	------------
	        255
	        254
	        253
	(3 rows)

A discussão colocada aqui é sobre a velocidade destas duas funções na versão 7.4. Experimentos feitos rodando o EXPLAIN ANALYSE mostraram que a função em plperl é mais rápida com ou sem carregar previamente as bibliotecas. No curso dos experimentos, um problema foi encontrado com o prévio carregamento da função do plperl. O problema foi que se a biblioteca não fosse encontrada ou não pudesse ser carregada, nenhum ERROR ou NOTICE era emitido. E a função de inicialização para plperl foi uma biblioteca estática e não poderia ser carregada dinamicamente de nenhuma maneira. Mas quem sabia? Ambos problemas serão corrigidos na versão 7.4 por Joe Conway do plperl, plpgsql, pltcl e plpython.

Na versão 7.4 você será capaz de carregar previamente bibliotecas de linguagens, usando a variável preload_libraries do arquivo postgresql.conf.

As funções de hexadecimal para decimal são boas, mas elas carecem de funções inversas assim como a habilidade de processar tamanhos de variáveis de strings hexadecimais. Isto é deixado como um exercício para o leitor :-)

Colaboradores: Claudio Lapidus clapidus em hotmail.com, Joe Conway mail em joeconway.com, Ron Johnson ron.l.johnson em cox.net, Tom Lane tgl em sss.pgh.pa.us