Index of /postgresql-8.2.5/FAQ/FAQ_brazilian.html |
Última atualização: Sáb Out 14 19:08:19 EDT 2006
Mantenedor atual: Bruce Momjian (bruce@momjian.us)
Traduzido por: Euler Taveira de Oliveira (euler@timbira.com)
A versão mais recente desse documento pode ser vista em
http://www.postgresql.org/files/documentation/faqs/FAQ.html (EN).
http://www.postgresql.org/files/documentation/faqs/FAQ_brazilian.html (pt_BR).
Perguntas sobre plataformas específicas são respondidas em http://www.postgresql.org/docs/faq/.
PostgreSQL é pronunciado Post-Gres-Q-L, e é, às vezes, referido apenas como Postgres. Um arquivo de áudio está disponível em formato MP3 para aqueles que gostariam de ouvir a pronúncia.
O PostgreSQL é um sistema de banco de dados objeto-relacional que tem as características de sistemas de bancos de dados comerciais tradicionais com melhoramentos encontrados nos sistemas SGBDs de próxima geração. PostgreSQL é livre e o código-fonte completo está disponível.
O desenvolvimento do PostgreSQL é feito por um grupo de desenvolvedores voluntários (na sua maioria) espalhados pelo mundo e que se comunicam via Internet. É um projeto da comunidade e não é controlado por nenhuma empresa. Para se envolver, veja a FAQ do desenvolvedor em http://www.postgresql.org/files/documentation/faqs/FAQ_DEV.html
Se você está procurando por um mantenedor, comitê central ou empresa controladora do PostgreSQL, desista --- não há um(a). Nós temos um comitê core e committers CVS, mas estes grupos são mais para questões administrativas do que controle. O projeto é direcionado pela comunidade de desenvolvedores e usuários, que qualquer um pode se juntar. Tudo o que você precisa é se inscrever nas listas de discussão e participar das discussões. Veja a FAQ do desenvolvedor para obter informações como se envolver com o desenvolvimento do PostgreSQL.
O PostgreSQL é distribuído sob a licença BSD clássica. Basicamente, ela permite que usuários façam qualquer coisa com o código, incluindo revender os binários sem o código-fonte. A única restrição é que você não nos responsabilize legalmente por problemas com o programa de computador. Há também a exigência de que esta licença apareça em todas as cópias do programa de computador. Aqui está a licença BSD que usamos atualmente:
PostgreSQL está sujeito a seguinte licença:
PostgreSQL Data Base Management System
Portions Copyright (c) 1996-2007, PostgreSQL Global Development Group Portions Copyright (c) 1994-1996 Regents of the University of California
Permission to use, copy, modify, and distribute this software and its documentation for any purpose, without fee, and without a written agreement is hereby granted, provided that the above copyright notice and this paragraph and the following two paragraphs appear in all copies.
IN NO EVENT SHALL THE UNIVERSITY OF CALIFORNIA BE LIABLE TO ANY PARTY FOR DIRECT, INDIRECT, SPECIAL, INCIDENTAL, OR CONSEQUENTIAL DAMAGES, INCLUDING LOST PROFITS, ARISING OUT OF THE USE OF THIS SOFTWARE AND ITS DOCUMENTATION, EVEN IF THE UNIVERSITY OF CALIFORNIA HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
THE UNIVERSITY OF CALIFORNIA SPECIFICALLY DISCLAIMS ANY WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE SOFTWARE PROVIDED HEREUNDER IS ON AN "AS IS" BASIS, AND THE UNIVERSITY OF CALIFORNIA HAS NO OBLIGATIONS TO PROVIDE MAINTENANCE, SUPPORT, UPDATES, ENHANCEMENTS, OR MODIFICATIONS.
Em geral, qualquer plataforma moderna compatível com Unix deve ser capaz de executar o PostgreSQL. As plataformas que foram testadas antes do lançamento de uma versão são listadas nas instruções de instalação.
O PostgreSQL também executa nativamente nos sistemas operacionais Microsoft Windows baseados no NT tais como Win200 SP4, WinXP e Win2003. Um instalador pré-empacotado está disponível em http://pgfoundry.org/projects/pginstaller. Versões do Windows baseadas no MS-DOS (Win95, Win98, WinMe) podem executar o PostgreSQL utilizando o Cygwin.
Há também uma versão para o Novell Netware 6 em http://forge.novell.com e uma versão para OS/2 (eComStation) em http://hobbes.nmsu.edu/cgi-bin/h-search?sh=1&button=Search&key=postgreSQL&stype=all&sort=type&dir=%2F.
Via navegador web, utilize http://www.postgresql.org/ftp/ e via ftp, utilize ftp://ftp.PostgreSQL.org/pub/.
A última versão do PostgreSQL é a versão 8.1.5.
Nós planejamos lançar versões novas a cada ano com versões corretivas em alguns meses.
A comunidade do PostgreSQL fornece assistência a muitos de seus usuários via e-mail. O principal sítio web para inscrição nas listas de e-mail é http://www.postgresql.org/community/lists/. As listas general e bugs são um bom lugar para início.
O principal canal de IRC é o #postgresql na Freenode (irc.freenode.net). Para se conectar você pode utilizar o comando Unix irc -c '#postgresql' "$USER" irc.freenode.net ou utilizar qualquer outro cliente de IRC. Um canal hispânico (#postgresql-es) e um francês (#postgresqlfr) também existem na mesma rede. Há também um canal PostgreSQL na EFNet.
Uma lista de empresas que prestam suporte comercial está disponível em http://www.postgresql.org/support/professional_support.
Visite o formulário que reporta bugs do PostgreSQL em http://www.postgresql.org/support/submitbug.
Verifique também o nosso ftp ftp://ftp.PostgreSQL.org/pub para ver se há uma versão mais recente do PostgreSQL.
Bugs submetidos utilizando o formulário ou informado a qualquer lista de discussão do PostgreSQL tipicamente gera uma das seguintes respostas:
O PostgreSQL suporta um subconjunto extendido do SQL:2003. Veja nossa lista de AFAZERES (TODO) que contém bugs conhecidos, funcionalidades ausentes e planos futuros.
Uma solicitação de funcionalidade geralmente resulta em uma das seguintes respostas:
O PostgreSQL não utiliza sistema de acompanhamento de bugs porque nós achamos mais eficiente responder diretamente o e-mail e manter a lista de AFAZERES (TODO) atualizada. Na prática, bugs não duram muito no programa; e bugs que afetam uma grande quantidade de usuários são corrigidos rapidamente. O único lugar para encontrar todas as mudanças, melhorias e correções em uma versão do PostgreSQL é ler as mensagens de log do CVS. Até mesmo as notas de lançamento não listam todas as mudanças feitas no programa.
O PostgreSQL inclui vasta documentação, incluindo um manual extenso, páginas de manuais (man pages) e alguns exemplos teste. Veja o diretório /doc. Você também pode pesquisar os manuais online em http://www.PostgreSQL.org/docs.
Há dois livros sobre PostgreSQL disponíveis online em http://www.postgresql.org/docs/books/awbook.html e http://www.commandprompt.com/ppbook/. Há uma lista de livros sobre PostgreSQL disponíveis para compra. Um dos mais populares é o do Korry Douglas. Uma lista de análise sobre os livros pode ser encontrada em http://techdocs.PostgreSQL.org/techdocs/bookreviews.php.
O programa cliente de linha de comando psql tem alguns comandos \d para mostrar informações sobre tipos, operadores, funções, agregações, etc. - utilize \? para mostrar os comandos disponíveis.
Nosso sítio web contém ainda mais documentação.
Primeiro, considere os livros específicos sobre PostgreSQL mencionados acima. Outro é o "Teach Yourself SQL in 21 Days, Second Edition" e http://members.tripod.com/er4ebus/sql/index.htm. Muitos de nossos usuários gostam do The Practical SQL Handbook, Bowman, Judith S., et al., Addison-Wesley. Outros do The Complete Reference SQL, Groff et al., McGraw-Hill.
Há também bons tutoriais disponíveis online:
Veja a FAQ do Desenvolvedor.
Há várias maneiras de se medir um software: funcionalidades, performance, confiabilidade, suporte e preço.
A instalação do PostgreSQL inclui somente as interfaces C e C embutida. Todas as outras interfaces são projetos independentes que podem ser obtidos separadamente; sendo separados permitem que eles tenham suas próprias datas de lançamento e time de desenvolvedores.
Algumas linguagens de programação como PHP incluem uma interface para PostgreSQL. Interfaces para linguagens como Perl, TCL, Python e muitas outras estão disponíveis em http://gborg.postgresql.org na seção de Drivers/Interfaces ou via busca na Internet.
Uma boa introdução para páginas web que utilizam bancos de dados pode ser vista em: http://www.webreview.com
Para integração na Web, PHP (http://www.php.net) é uma excelente interface.
Para casos complexos, muitos usam a Interface Perl e DBD::Pg com CGI.pm ou mod_perl.
Há um vasto número de Ferramentas Gráficas (GUI), que estão disponíveis para o PostgreSQL, comerciais e de desenvolvedores de código aberto. Uma lista detalhada pode ser encontrada em Documentação da Comunidade PostgreSQL
Especifique a opção --prefix quando executar o configure.
Por padrão, o PostgreSQL só permite conexões da máquina local utilizando soquetes de domínio Unix ou conexões TCP/IP. Outras máquinas não poderão conectar-se a menos que você modifique listen_addresses no postgresql.conf, habilite a autenticação por máquina modificando o arquivo $PGDATA/pg_hba.conf e reinicie o servidor PostgreSQL.
Há três grandes áreas para melhorar a performance em potencial:
Há muitas variáveis de configuração do servidor log_*
que habilitam a exibição de consultas e estatísticas que podem ser
muito úteis para depuração e medidas de performance.
Você atingiu o limite padrão que é de 100 sessões. Você precisa aumentar o limite do postmaster, que diz quantos processos servidor concorrentes ele pode iniciar, alterando o valor max_connections no postgresql.conf e reiniciando o postmaster.
O time do PostgreSQL faz somente pequenas mudanças entre versões corretivas, então atualizar da versão 7.4.8 para 7.4.9 não requer uma exportação e uma importação; basta para o servidor de banco de dados, instalar os binários atualizados e reiniciar o servidor.
Todos os usuários devem atualizar para as versões corretivas mais recentes assim que elas estiverem disponíveis. Enquanto cada atualização tem algum risco, versões corretivas do PostgreSQL são projetadas para corrigir somente bugs comuns com um risco mínimo. A comunidade considera não atualizar mais perigoso do que atualizar.
Versões novas (i.e. da 7.3 para 7.4) geralmente muda-se o formato interno das tabelas de sistema e dos arquivo de dados. Essas mudanças geralmente são complexas, então nós não mantemos compatibilidade para os arquivos de dados. Uma exportação/importação de um banco de dados é necessária para atualizações entre versões.
Por causa do hardware de PC ser em sua maioria compatível, pessoas tendem a acreditar que todos os hardwares de PC são de mesma qualidade. Não é verdade. ECC RAM, SCSI e placas mãe de qualidade são mais confiáveis e têm uma melhor performance do que hardwares mais baratos. O PostgreSQL executará em quase todo hardware, mas se a confiabilidade e a performance forem importantes é prudente pesquisar sobre as opções de hardware. Nossas listas de discussão podem ser usadas para discutir opções de hardware e dilemas.
Para obter somente alguns registros, se você sabe o número de registros necessários ao executar o SELECT utilize o LIMIT. Se um índice corresponde no ORDER BY é possível que a consulta toda não tenha que ser executada. Se você não sabe o número de registros ao executar o SELECT, utilize um cursor e o FETCH.
Para obter um registro randômico, utilize:
SELECT col
FROM tab
ORDER BY random()
LIMIT 1;
Utilize o comando \dt para ver tabelas no psql. Para obter uma lista completa dos comandos no psql você pode utilizar \?. Alternativamente, você pode ler o código-fonte do psql no arquivo pgsql/src/bin/psql/describe.c, ele contém os comandos SQL que geram a saída para os comandos de contrabarra do psql. Você também pode iniciar o psql com a opção -E para que as consultas utilizadas para executar os comandos que você informou seja exibida. O PostgreSQL também fornece uma inteface compatível com SQL do INFORMATION SCHEMA que você pode consultar para obter informação sobre o banco de dados.
Há também tabelas do sistema que começam com pg_ que os descrevem também.
Utilizando o psql -l listará todos os bancos de dados.
Veja também o arquivo pgsql/src/tutorial/syscat.source. Ele ilustra muitos dos comandos SELECTs necessários para obter informação das tabelas de sistema do banco de dados.
Mudar o tipo de dado de uma coluna pode ser feito facilmente na versão 8.0 ou superior com ALTER TABLE ALTER COLUMN TYPE.
Em versões anteriores, faça isso:
BEGIN;
ALTER TABLE tab ADD COLUMN col_nova novo_tipo_dado;
UPDATE tab SET col_nova = CAST(col_antiga AS novo_tipo_dado);
ALTER TABLE tab DROP COLUMN col_antiga;
COMMIT;
Você pode então querer fazer um VACUUM FULL tab para recuperar o espaço em disco utilizado pelos registros expirados.
Estes são os limites:
Tamanho máximo de um banco de dados? ilimitado (existem bancos de dados de 32 TB) Tamanho máximo de uma tabela? 32 TB Tamanho máximo de um registro? 400 GB Tamanho máximo de um campo? 1 GB Número máximo de registros em uma tabela? ilimitado Número máximo de colunas em uma tabela? 250-1600 dependendo dos tipos das colunas Número máximo de índices em uma tabela? ilimitado
É claro, que eles não são ilimitados, mas limitados ao espaço em disco disponível e espaço em memória/swap. A Performance será penalizada quando estes valores se tornarem grandes.
O tamanho máximo de uma tabela com 32 TB não requer suporte a arquivos grandes do sistema operacional. Tabelas grandes são armazenadas como múltiplos arquivos de 1 GB então o limite do sistema de arquivos não é importante.
O tamanho máximo de uma tabela, o tamanho de um registro e o número máximo de colunas podem ser quadruplicados aumentando-se o tamanho padrão do bloco para 32k. O tamanho máximo de uma tabela pode também ser aumentado utilizando particionamento de tabela.
Uma limitação é que índices não podem ser criados em colunas maiores do que 2.000 caracteres. Felizmente, tais índices são raramente necessários. Unicidade é melhor garantida por um índice de uma função de um hash MD5 de uma coluna longa, e indexação de texto longo permite a busca de palavras dentro da coluna.
Um banco de dados PostgreSQL irá requerer até cinco vezes a quantidade de espaço requerida para armazenar dados em um arquivo texto.
Como um exemplo, considere um arquivo com 100.000 linhas contendo um inteiro e uma descrição em cada linha. Suponha que o tamanho médio da descrição é de vinte bytes. O arquivo terá 2,8 MB. O tamanho do arquivo do banco de dados PostgreSQL que contém esses dados pode ser estimado em 5,6 MB:
28 bytes: cada cabeçalho de registro (aproximadamente)
24 bytes: um campo int e um campo texto
+ 4 bytes: ponteiro na página para a tupla
-------------------------------------------
56 bytes por registro
O tamanho de uma página de dados no PostgreSQL é 8192 bytes (8 KB), então:
8192 bytes por página
------------------------ = 146 registros por página do banco de dados (arredondado para baixo)
56 bytes por registro
100000 registros de dados
---------------------------- = 685 páginas do banco de dados (arredondado para cima)
146 registros por página
685 páginas do banco de dados * 8192 bytes por página = 5.611.520 bytes (5,6 MB)
Índices não requerem muito espaço, mas contém dados que foram indexados, então eles podem ocupar algum espaço.
NULLs são armazenados como bitmaps, então eles utilizam muito pouco espaço.
Índices não são utilizados por toda consulta. Índices são utilizados somente se a tabela é maior do que um tamanho mínimo, e a consulta seleciona somente uma pequena porcentagem dos registros da tabela. Isto porque o acesso randômico ao disco causado pela busca indexada pode ser mais lento do que uma leitura ao longo da tabela ou busca sequencial.
Para determinar se um índice deveria ser utilizado, o PostgreSQL deve ter estatísticas sobre a tabela. Estas estatísticas são coletadas utilizando o VACUUM ANALYZE ou simplesmente o ANALYZE. Utilizando estatísticas, o otimizador sbae quantos registros estão na tabela, e pode melhor determinar se índices deveriam ser utilizados. Estatísticas também são úteis para determinar a ordem de junção ótima e métodos de junção. Coleção de estatísticas deveriam ser feitas periodicamente a medida que o conteúdo da tabela muda.
Índices não são normalmente utilizados para ORDER BY ou para fazer junções. Uma busca sequencial seguido por uma ordenação explícita é geralmente mais rápida do que uma busca indexada em uma tabela grande. Contudo, LIMIT combinado com ORDER BY frequentemente utilizará índice porque somente uma pequena porção da tabela será retornada.
Se você acredita que o otimizador está incorreto ao escolher uma busca
sequencial, utilize SET enable_seqscan TO 'off' e execute a
consulta novamente para ver se uma busca indexada é realmente mais rápida.
Ao utilizar operadores curinga tais como LIKE ou ~, índices podem ser utilizados somente em algumas condições:
text_pattern_ops para tais casos
que funcionam somente para indexação com LIKE.
Em versões anteriores a 8.0, índices frequentemente não podem ser utilizados a menos que os tipos de dados correspondam aos tipos de coluna do índice. Isto era particularmente verdadeiro para índices de coluna int2, int8 e numeric.
Veja o comando EXPLAIN no manual.
O operador ~ faz avaliação de expressões regulares, e ~* faz avaliação não sensível a maiúsculas de expressões regulares. A variante não sensível a maiúsculas do LIKE é chamada de ILIKE.
Comparações de igualdade não sensíveis a maiúsculas são normalmente expressadas como:
SELECT *
FROM tab
WHERE lower(col) = 'abc';
Isso não irá utilizar o índice padrão. Contudo, se
você criar um índice de expressão, ele será utilizado:
CREATE INDEX tabindex ON tab (lower(col));
Se o índice acima é criado como UNIQUE, embora a coluna possa armazenar caracteres maiúsculos e minúsculos, ele não pode ter valores idênticos que diferem apenas em letras maiúsculas e minúsculas. Para forçar uma letra maiúscula ou minúscula a ser armazenada na coluna, utilize uma restrição CHECK ou um gatilho.
Você testa a coluna com IS NULL e IS NOT NULL, como a seguir:
SELECT * FROM tab WHERE col IS NULL;
Para ordenar pelo status NULL, utilize os modificadores IS NULL e IS NOT NULL na sua cláusula ORDER BY. Coisas que são verdadeiro serão ordenadas acima das coisas que são falso, então a consulta a seguir irá colocar entradas NULL no início da lista de resultados:
SELECT * FROM tab ORDER BY (col IS NOT NULL)
Tipo Nome Interno Observação VARCHAR(n) varchar tamanho especifica o tamanho máximo, sem preenchimento CHAR(n) bpchar preenchimento em branco para comprimento fixo específico TEXT text nenhum limite superior específico no comprimento BYTEA bytea vetor de bytes de comprimento variável (seguro a byte nulo) "char" char um caracter
Você verá o nome interno quando examinar o catálogo do sistema e em algumas mensagens de erro.
Os primeiros quatro tipos acima são do tipo "varlena" (i.e., os primeiros quatro bytes no disco são o comprimento seguido pelos dados). Consequentemente o espaço atual utilizado é ligeiramente maior do que o tamanho declarado. Contudo, valores longos são também sujeitos a compressão, então o espaço em disco pode também ser bem menor do que o esperado.
VARCHAR(n) é melhor quando está armazenando cadeias de caracteres de comprimento variável e há um limite de tamanho desta cadeia. TEXT é para cadeias de caracteres de comprimento ilimitado, com o máximo de um gigabyte.CHAR(n) é para armazenar cadeias de caracteres que são todas do mesmo tamanho. CHAR(n) preenche com espaços em branco até o tamanho especificado, enquanto o VARCHAR(n) armazena somente os caracteres fornecidos. BYTEA é para armazenar dados binários, particularmente valores que incluem bytes NULL. Todos os tipos descritos aqui tem características de performance similares.
PostgreSQL suporta o tipo de dados SERIAL. Ele cria automaticamente uma sequência. Por exemplo:
CREATE TABLE pessoa (
id SERIAL,
nome TEXT
);
é automaticamente traduzido em:
CREATE SEQUENCE pessoa_id_seq;
CREATE TABLE pessoa (
id INT4 NOT NULL DEFAULT nextval('pessoa_id_seq'),
nome TEXT
);
Veja a página sobre create_sequence no manual para
obter informações adicionais sobre sequências.
Uma abordagem é obter o próximo valor SERIAL de uma sequência com a função nextval() antes de inserir e então inserir com o valor explicitamente. Utilizando o exemplo da tabela em 4.11.1, um exemplo em pseudo-linguagem se pareceria com isto:
novo_id = execute("SELECT nextval('pessoa_id_seq')");
execute("INSERT INTO pessoa (id, nome) VALUES (novo_id, 'Blaise Pascal')");
Você poderia então ter também o novo valor armazenado em
novo_id para utilizar em outras consultas (i.e., como uma chave
estrangeira da tabela pessoa). Note que o nome da
SEQUENCE criada automaticamente será
<tabela>_<coluna>_seq, onde
tabela e coluna são os nomes da tabela
e da coluna SERIAL, respectivamente.
Alternativamente, você poderia obter o valor SERIAL atribuído com a função currval() depois de tê-lo inserido por padrão, i.e.,
execute("INSERT INTO pessoa (nome) VALUES ('Blaise Pascal')");
novo_id = execute("SELECT currval('pessoa_id_seq')");
Não. currval() retorna o valor atual atribuido pela sua sessão, e não por todas as sessões.
Para melhorar a concorrência, valores da sequência são atribuídos a transações correntes e não são travados até que a transação seja finalizada. Isso causa intervalos na numeração por causa de transações abortadas.
Cada registro que é criado no PostgreSQL recebe um OID único a menos que seja criado com WITHOUT OIDS. OIDs são automaticamente atribuídos como inteiros de 4 bytes que são únicos ao longo de toda instalação. Contudo, eles são limitados em 4 bilhões, e então os OIDs começam a ser duplicados. O PostgreSQL utiliza OIDs para ligar as tabelas do sistema.
Para numerar registros nas tabelas do usuários, é melhor utilizar SERIAL ao invés de OIDs porque sequências SERIAL são únicas somente em uma tabela; e são menos propícias a atingir o limite. SERIAL8 está disponível para armazenar valores de sequências com oito bytes.
CTIDs são utilizados para identificar registros físicos específicos com valores de block e deslocamento. CTIDs mudam após registros serem modificados ou recarregados. Eles são utilizados por índices para apontar registros físicos.
Você provavelmente está sem memória virtual no seu sistema, ou o seu núcleo (kernel) tem um limite baixo para certos recursos. Tente isto antes de iniciar o postmaster:
ulimit -d 262144
limit datasize 256m
Dependendo da sua shell, somente um desses comando terá sucesso, mas ele definirá o segmento de dados do seu processo com um limite maior e talvez permita que a consulta seja feita. Este comando é aplicado ao processo atual e todos os subprocessos criados depois do comando ser executado. Se você tiver problemas com o cliente SQL porque o processo servidor retornou muitos dados, tente-o antes de iniciar o cliente.
No psql, digite SELECT version();
Utilize CURRENT_TIMESTAMP:
CREATE TABLE teste (x int, modtime timestamp DEFAULT CURRENT_TIMESTAMP );
PostgreSQL suporta junções externas utilizando a sintaxe padrão do SQL. Aqui temos dois exemplos:
SELECT *
FROM t1 LEFT OUTER JOIN t2 ON (t1.col = t2.col);
or
SELECT *
FROM t1 LEFT OUTER JOIN t2 USING (col);
Essas duas consultas indênticas juntam t1.col com t2.col, e também retornam qualquer registro que não foi juntado em t1 (aqueles que não combinaram com t2). Uma junção a direita RIGHT adicionaria registros que não foram juntados da tabela t2. Uma junção completa (FULL) retornaria os registros combinados mais todos os registros não combinados de t1 e t2. A palavra OUTER é opcional e é assumida nas junções LEFT, RIGHT e FULL. Junções ordinárias são chamadas junções naturais (INNER).
Não há outra maneira de consultar um banco de dados caso ele não seja o atual. Porque o PostgreSQL carrega catálogos do sistema específicos do banco de dados, é incerto como uma consulta em banco de dados distintos pode se comportar.
contrib/dblink permite consultas em bancos de dados distintos utilizando chamadas de funções. É claro, que um cliente pode fazer conexões simultâneas em bancos de dados diferentes e juntar os resultados no cliente.
É fácil utilizando funções que retornam conjunto, http://techdocs.postgresql.org/guides/SetReturningFunctions.
PL/PgSQL armazena o conteúdo da função, e o efeito indesejado é que se uma função PL/PgSQL acessa uma tabela temporária, e aquela tabela é removida e criada novamente, e a função é chamada novamente, a função irá falhar porque o conteúdo armazenado da função ainda apontará para a tabela temporária antiga. A solução é utilizar o EXECUTE para acesso a tabelas temporárias no PL/PgSQL. Isto irá fazer com que a consulta seja avaliada toda vez.
Embora "replicação" seja um termo simples, há várias tecnologias para fazer replicação, com vantagens e desvantagens para cada um.
Replicação mestre/escravo permite que um mestre receba consultas de leitura e escrita, enquanto os escravos só podem aceitar leitura/consultas SELECT. A solução mais popular de replicação mestre-escravo para PostgreSQL disponível livremente é Slony-I.
Replicação com múltiplos mestres permite que consultas leitura/escrita sejam enviadas para múltiplos computadores replicadores. Esta capacidade também tem um sério impacto na performance por causa da necessidade de sincronizar as mudanças entre os servidores. Pgcluster é a solução mais popular disponível livremente para PostgreSQL.
Há também soluções de replicação comerciais e baseadas em hardware disponíveis que suportam uma variedade de modelos de replicação.
O caso mais comum é o uso de aspas ao redor dos nomes da tabela ou coluna durante a criação da tabela. Ao utilizar aspas, nomes de tabela e coluna (chamados de identificadores) são armazenados como especificado, significando que você deve utilizar aspas quando se referir aos nomes na consulta. Algumas interfaces, como pgAdmin, automaticamente coloca aspas nos identificadores durante a criação da tabela. Então, para identificadores serem reconhecidos, você deve:
HIVE: All information for read only. Please respect copyright! |
