AE
By A. Elein Mustain
Traduzidos por Juliano da Silva Ignacio
General Bits 7-Jul-2003 Edição: 33


General Bits é uma coluna baseada na lista de discussão do PostgreSQL pgsql-general.
Para saber mais sobre a lista de discussão pgsql-general e sobre o PostgreSQL, procure em http://www.postgresql.org/.
Arquivos
General Tidbits
Artigos Português
Artículos en Castellanos
7.4 Documentación
Google General Bits
Notícias
Para receber um aviso via email sobre as novas edições do General Bits, envie um email para Elein.
PostgreSQL Consulting, Support & Training
Assinaturas
 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Ajustando a Performance e o Arquivo Comentado postgresql.conf -- por Josh Berkus & Shridhar Daithankar
A mais recente versão da documentação do arquivo postgresql.conf 3/Jul/2003

Assim como muitos de nós têm se antecipado, Josh Berkus, juntamente com a ajuda de Shridhar Daithankar, disponibilizaram ambos, dois maravilhosos documentos para ajudar qualquer pessoa a classificar em detalhes o arquivo postgresql.conf e as opções do GUC (Configuração Global do Usuário).

O primeiro documento, Ajustando a Performance do PostgreSQL é um conjunto de passos e questões a serem feitas quando estiver se preparando para ajustar uma instalação.

No segundo documento, O Arquivo Comentado postgresql.conf, os elementos do arquivo postgresql.conf são muito bem organizados em grupos funcionais. Cada item é documentado com seu intervalo, valor padrão, variável correspondente e a opção -o, todas descritas em detalhes. Os comentários da maioria dos itens também dão à você um claro entendimento de como e quando configurar estas variáveis e qual impacto deveria ser esperado.

Ambos documentos são de leitura praticamente obrigatória para aqueles que planejam configurar uma instalação de produção do PostgreSQL.

Colaboradores: Josh Berkus em agliodbs.com, Shridhar Daithankar em persistent.co.in

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Pesquisando sem acentos
[GENERAL] Pesquisa insensível aos acentos 1/Jul/2003

Na necessidade de pesquisar dados ignorando acentos, você deve converter o dado para ASCII.

Uma tabela contendo os seguintes dados e, selecionado com a claúsula comum LIKE, retornaria à você somente "Polo".

	--------
	Colón
	Polo
	--------
	SELECT * 
	FROM testtable 
	WHERE testfield like '%olo%';
Se você selecionar de uma tabela convertendo para ASCII, retornaria à você ambos os valores:
	SELECT * 
	FROM testtable 
	WHERE to_ascii(testfield,'LATIN1') LIKE '%olo%'
Esta solução ainda não foi testada em um banco de dados com a tabela de caracteres UNICODE devido a uma mensagem de aviso que poderia não funcionar neste caso.

Colaboradores: Alejandro Javier Pomeraniec apomeraniec em buenosaires.gov.ar, Ian Barwick barwick em gmx.net, Alvaro Herrera alvherre em dcc.uchile.cl

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Índices Redundantes e de Múltiplas Colunas
[GENERAL] Q: Índice estruturado - qual deles executa mais rápido? 22/Mai/2003

Para uma tabela com uma chave mista composta de três partes, a questão levantada foi se um índice funcional de campos concatenados não seria mais rápido do que esta chave mista. Os índices seriam:

	create index threepart on table foo (col_one, col_two, col_three);
	create index catthree on table foo ( cattext3(col_one, col_two, col_three));
onde cattext3() é uma função de concatenação que retorna seus três argurmentos concatenados.

É de comum acordo que uma chave mista composta de três partes é melhor do que o índice funcional de mesmo conteúdo por diversas razões. Principalmente se o "menor não-único" valor é o mais à esquerda da definição do índice, o índice de chave mista será mais rápido.

Os índices de múltiplas partes em geral são muito mais flexíveis também. Pesquisas com índices parciais podem usar os índices de múltiplas partes. Por exemplo, se você pesquisasse somente pela col_one, a primeira parte do índice de múltiplas partes seria usada. O índice de múltiplas partes não seria usado para pesquisar col_two sem que esta seja precedida pela col_one, porém, isto também não funcionaria em um índice funcional.

Em uma questão relacionada, se a tabela possui um índice de três partes e um outro índice somente com col_one, o índice de col_one sozinha seria redundante. Não há necessidade de criar ou armazenar um segundo índice quando o primeiro irá fazer o trabalho.

Colaboradores: Ernest E Vogelsinger ernest em vogelsinger.at, Tom Lane tgl em sss.pgh.pa.us, Vivek Khera khera em kcilink.com, Bruno Wolff III bruno em wolff.to, Manfred Koizar mkoi-pg em aon.at, scott.marlowe scott.marlowe em ihs.com, Reece Hart rkh em gene.COM

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

O que é $libdir
[GENERAL] Problema de instalação: não encontra $libdir 2/Jul/2003

Quando instalamos linguagens, como plpgsql em um banco de dados, o sistema verifica se o diretório $libdir existe. $libdir é uma representação do PostgreSQL para um diretório especificado no caminho (path) da biblioteca de objetos compartilhados quando o PostgreSQL é configurado.

Se você configurou com --prefix=/local/pgsql73, por exemplo, a representação $libdir é expandida para /local/pgsql73/lib. O valor de $libdir é geralmente o resultado da concatenação de outros padrões como --prefix=PREFIX --exec-prefix=EPREFIX e --libdir=dir.
PREFIX contém o valor padrão /usr/local/pgsql.
EPREFIX contém o valor padrão PREFIX.
$libdir contém o valor padrão EPREFIX/lib

A localização de $libdir também é importante quando escrevemos funções em C. Quando você define uma função em C dentro de uma instrução em SQL, você deve especificar a localização do objeto compartilhado da sua função (.so). Você pode usar $libdir literalmente dentro da definição em SQL para sinalizar que seu objeto compartilhado está na sua definição de instalação de $libdir

	CREATE FUNCTION hello_cstr()
	RETURNS cstring
	AS '$libdir/hello_cstr.so'
	LANGUAGE 'c';

Não é necessário que $libdir seja usada para funções de objetos compartilhados em linguagem C. Também é possível especificar o nome do caminho completo do desenvolvimento ou do armazenamento de objetos compartilhados em diretórios alternativos.

Colaboradores: Rich Cullingford rculling em sysd.com, Tom Lane tgl em sss.pgh.pa.us, elein em varlena.com

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Duas Instalações na mesma máquina
[GENERAL] 2 versões diferentes do postgres no mesmo sistema 1/Jul/2003

Possuir duas instalações separadas na mesma máquina é extremamente favorável. Com a versão beta do 7.4 saindo, muitas pessoas irão querer manter suas instalações existentes e ainda serem capaz de testar a instalação do 7.4.

Há três elementos chaves na criação de instalações separadas, localização da instalação, localização do diretório de dados e o acesso dos clientes. A localização da instalação é determinada em tempo de configuração fixando o prefixo de criação em um diretório específico ao invés do diretório padrão. A localização do diretório de dados é determinada com o initdb. O acesso dos clientes é determinado fixando as variáveis PG apropriadas e assegurando que o apropriado diretório bin da instalação apareça antes na definição da variável de ambiente PATH do que a outra.

Para construir uma instalação da versão 7.4 no diretório /local/pgsql74 você deveria usar:

	./configure --prefix=/local/pgsql74 ... 
Quando o install for executado, todas as partes da instalação serão instaladas a partir do mesmo diretório.

Depois você precisa determinar onde o diretório de dados para a instalação irá ser criado. Existe uma grande preferência pelo diretório PREFIX/data pelo fato de não estar em um diretório específico de bancos de dados de superusuários e não será confundido com outras instalações. Para configurar o diretório de dados, então use:

	initdb -D /local/pgsql74/data 

Na Edição 12, uma convenção para configuração de ambiente usuário foi descrita. Consiste de um arquivo de ambiente chamado pgenv o qual é usado no ambiente cliente para configurar as variáveis padrão de ambiente do PG. PG_INST não é uma variável comum ao PG; ela foi criada por conveniência.

	PG_INST=/local/pgsql74
	PGDATA=$PG_INST/data
	PGPORT=5433
	PGLIB=$PG_INST/lib
	PATH=$PG_INST/bin:$PATH
	PGHOST=cookie
	PGDATABASE=production
	export PG_INST PGDATA PGHOST PGPORT PATH PGLIB PGDATABASE

Como descrito anteriormente estas variáveis podem set configuradas em um .profile de um usuário ou em um /etc/profile para fixar a instalação padrão do sistema. Alternativamente, duas versões do arquivo podem ser mantidas disponíveis, no entanto, com as chamadas pgenv73 e pgenv74, dessa maneira, quando mudar de um para outro, será somente a tarefa de carregar o arquivo correto.

Note que este arquivo pgenv altera a variável de ambiente PATH existente. Isto é importante, principalmente se uma de suas instalações estiver dentro de /usr/local/bin. Você deve se certificar que os executáveis para a instalação escolhida virão antes dos outros em seu PATH.

Colaboradores: elein em varlena.com, Madhavi Daroor madhavi em zoniac.com, Arguile arguile em lucentstudios.com, scott.marlowe scott.marlowe em ihs.com


Comments and Corrections are welcome. Suggestions and contributions of items are also welcome. Send them in!.
Copyright A. Elein Mustain 2003

Comentários e Correções são bem vindos. Sugestões e contribuições de itens também são bem vindos. Envie-os!
Copyright A. Elein Mustain 2003, 2004, 2005
Traduzidos por Juliano da Silva Ignacio
Google
Search General Bits & varlena.com Search WWW