Jmoney38's questions

No momento, estou escrevendo uma função plpgsql que selecionará em uma tabela e produzirá uma quantidade substancial de dados.

Originalmente, eu retornaria uma matriz, mas encontrei um recurso que explica a operação " RETURN NEXT - Muito útil para chamadores.

No entanto, li esta sinopse que é preocupante:

Nota: A implementação atual de RETURN NEXT e RETURN QUERY armazena todo o conjunto de resultados antes de retornar da função, conforme discutido acima. Isso significa que, se uma função PL/pgSQL produzir um conjunto de resultados muito grande, o desempenho poderá ser ruim:

Existe um recurso do Postgres que permita que minha função transmita os resultados de volta para o chamador à medida que são produzidos? Isso pode ser uma limitação da arquitetura do Postgres em geral, mas quero ter certeza de que não estou esquecendo nada!

Eu tenho duas tabelas com uma chave estrangeira de T1->T2, em um relacionamento um-para-muitos. Ou seja, 1 tupla na tabela T1 está associada a 0..N tuplas em T2.

Para criar um exemplo simples, digamos que T1 é Carros e T2 é uma tabela de imperfeições. Então, um carro pode ter 0..N imperfeições, e armazenamos essas imperfeições em T2 como números inteiros.

Eu gostaria de selecionar * apenas daqueles carros em Carros que contêm imperfeições i1 E i2.

Em vez disso, executar uma OU é muito fácil:

SELECT * FROM cars AS T1 
  WHERE EXISTS (
    SELECT imperfection FROM Imperfections as T2 
      WHERE T1.uid = T2.uid AND (imperfection = 1 OR imperfection = 2)
  );

Tenho tentado definir a lógica usando a interseção, mas, neste ponto, estou me perguntando se estou complicando demais.

Pergunta bastante simples para a qual não consigo encontrar uma resposta - estou trabalhando com uniões e diferenças e gostaria de realizar uma CONTAGEM nos resultados. Atualmente, estou tendo que canalizar para um arquivo e "wc -l" o arquivo (menos 4 para a impressão do Postgres). Deve haver uma maneira de incluir COUNT...

SELECT tbl1.id EXCEPT (SELECT tbl2.id UNION tbl3.id); 

Gostaria de saber o número de resultados após a diferença de set. Obrigado por qualquer entrada!

Estou executando um script plpgsql no Postgres 8.3 - gostaria de passar argumentos para este script via psql. Atualmente estou executando o script como:

psql -d database -u user -f update_file.sql 

Me deparei com este link que explica a variável de ambiente PGOPTIONS, mas isso não funciona para argumentos "personalizados". ou seja, recebo um erro porque a configuração não está listada no arquivo postgres.conf.

-bash-3.2$ export PGOPTIONS='--pretend=true'
-bash-3.2$ psql -d my_db -f update_database.sql
psql: FATAL:  unrecognized configuration parameter "pretend"

Alguma outra ideia? Idealmente, eu gostaria de evitar variáveis ​​​​de ambiente ...

Pergunta bastante simples, provavelmente respondida em algum lugar, mas não consigo formular a pergunta de pesquisa correta para o Google ...

O número de colunas em uma tabela específica afeta o desempenho de uma consulta, ao consultar um subconjunto dessa tabela?

Por exemplo, se a tabela Foo tiver 20 colunas, mas minha consulta selecionar apenas 5 dessas colunas, ter 20 (versus, digamos, 10) colunas afetará o desempenho da consulta? Para simplificar, suponha que qualquer coisa na cláusula WHERE esteja incluída nessas 5 colunas.

Estou preocupado com o uso do cache de buffer do Postgres, além do cache de disco do sistema operacional. Perco muito a compreensão do design de armazenamento físico do Postgres. As tabelas são armazenadas em várias páginas (o padrão é 8k de tamanho por página), mas não entendo muito bem como as tuplas são organizadas a partir daí. O PG é inteligente o suficiente para buscar apenas no disco os dados que compreendem essas 5 colunas?

Eu li vários artigos (incluindo documentos do Postgres) que sugerem definir o valor de configuração do shared_buffer para 25% de sua memória física total.

Usando minha memória de 4 GB como exemplo ... Se bem entendi, quando o postgres é iniciado, ele solicita ~ 1 GB de memória física do sistema operacional. Ele usará isso para fins de buffer. Assim, quando olho para um utilitário como "top", vejo que o tamanho/RES do processo postgres é de aproximadamente 1 GB.

Portanto, minha pergunta é: o que acontece quando tenho conexões POOLED com o Postgres? ou seja, um servidor Tomcat que mantém N número de conexões abertas e ociosas para postgres? Posso ver que há um número N de processos postgress aguardando em segundo plano por solicitações do Tomcat. Cada processo tem o mesmo tamanho (~1Gb). Eles são garfos do processo original, suponho. Isso significa que o Postgres como um todo está ocupando N * 1 GB de memória? Não é uma coisa ruim tornar o shared_buffer tão grande?

Quando executo o comando EXPLAIN ANALYZE em uma determinada consulta, estou tendo dificuldade em interpretar o valor de tempo de saída. Por exemplo (tempo real=8163.890..8163.893). Os decimais internos representam caracteres repetidos? Desculpe, esta pode ser uma pergunta noobish, mas quero ter certeza de que estou interpretando os resultados corretamente.

   ->  GroupAggregate  (cost=2928781.21..2929243.02 rows=1 width=27712) (actual time=8163.890..8163.893 rows=1 loops=1)