|
|||||||||||||||||||||||||||||||||
|
|||||||||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
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.
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.
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.
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. 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.
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.
| ||||||||||||||||||||||||||||||||
Comments and Corrections are welcome. Suggestions and contributions of items are also welcome. Send them in!. Copyright A. Elein Mustain 2003 |