David's questions

Eu tenho uma tabela bem central em nosso banco de dados que é utilizada por uma série de aplicações, ela possui regras atreladas a ela, triggers e todas as dependências que você possa imaginar. Agora gostaria de modificar a tabela sem causar problemas nas dependências. Anteriormente, consegui fazer o seguinte, mas em um caso muito menos complexo:

alter table reconciliations rename to matches;
create view reconciliations as select * from matches;

O que isso significa é que agora eu poderia modificar a nova tabela "correspondências" e, por exemplo, adicionar uma coluna ou linhas, que não precisam ser apresentadas na exibição "reconciliações" (adicionando uma cláusula where para filtrá-las).

Estou no Postgres 9.5, então a visualização é atualizável automaticamente. Os testes iniciais mostram que não há problemas imediatos com isso, então estou fazendo esta pergunta para saber que tipo de problema devo procurar. O desempenho não é um grande problema.

Tenho as seguintes relações:

CREATE TABLE cities (
    city VARCHAR (80) PRIMARY KEY,
    LOCATION point
);

CREATE TABLE weather (
    city VARCHAR (80) REFERENCES cities (city),
    temp_lo INT,
    temp_hi INT,
    prcp REAL,
    DATE DATE
);

CREATE VIEW test AS SELECT
    *
FROM
    cities;

Agora, gostaria de utilizar a visualização de teste ou qualquer outra visualização em uma GUI que simplesmente apresente uma tabela editável. Isso é possível com as exibições atualizáveis ​​automaticamente introduzidas recentemente. Eu quero que a tabela contenha drop-downs contendo todos os valores possíveis toda vez que houver uma coluna com restrições, como a coluna com uma chave estrangeira neste caso.

Como isso pode ser alcançado? Eu sei que poderia utilizar enums e faço isso hoje, mas no Amazon RDS eles são excessivamente difíceis de modificar arquivos .

Tive a ideia de (ab)usar a consulta "EXPLAIN SELECT" para cada coluna e verificar qual tabela e coluna está sendo consultada.

Estamos criando SAAS onde teremos no máximo 50.000 clientes. Estamos pensando em criar um usuário no banco de dados Postgres para cada cliente. Vamos mapear cada usuário que faz login em nosso serviço para um usuário no banco de dados para ter certeza de que ele só terá acesso aos seus próprios dados. Também queremos implementar uma trilha de auditoria diretamente no banco de dados por esta solução , que utiliza gatilhos. Se cada cliente tiver seu próprio usuário de banco de dados, será muito fácil ver quem fez o quê, mesmo que dois clientes compartilhem os mesmos dados.

Estaremos enfrentando alguns problemas inesperados porque temos 50.000 usuários em nosso banco de dados? Em termos de desempenho ou administração. Talvez o pool de conexões seja mais difícil, mas não sei se precisaríamos disso.

Pelo que entendi, pode haver uma busca de disco por rotação de um disco rígido, portanto, estou interessado em saber quantas buscas de disco são necessárias para gravar uma linha em uma tabela SQLite, incluindo bloqueio etc. Suponha que não haja índices na mesa (nem mesmo uma chave primária). Presumo que haja um disco para gravar uma linha em um arquivo? Como você entende, quero comparar o desempenho com a gravação dos mesmos dados em um arquivo simples.

Estou considerando um modelo em que uso PostgreSQL COPY para copiar dados de um arquivo para uma tabela. Eu queria saber que tipo de desempenho esperar em hardware de ponta. Um intervalo em MB/s seria bom para que eu possa começar a estimar. Se você apenas souber a resposta em outros bancos de dados, eu estaria interessado em comparar.

Estou pensando em contratar alguém para implementar o processamento de GPU no Postgres para acelerar varreduras sequenciais em um banco de dados localizado em um ramdisk. Quanto você acredita que eu poderia ganhar usando essa abordagem? Eu poderia comprar qualquer tipo de placa gráfica. Eu sei que esta pergunta é muito difícil, mas eu sei muito pouco sobre GPU, então um palpite bem aproximado me ajudaria muito.

EDIT: Embora meu interesse seja especificamente para Postgres, eu poderia fazer esta pergunta de uma maneira diferente: "Qual é o aumento potencial de desempenho usando GPU para varreduras sequenciais em um banco de dados na memória". Se a resposta for que ele tem um potencial de 10 a 50 vezes o desempenho, posso começar a investigar mais especificamente se isso também pode ser realizado no Postgres.

Preciso migrar continuamente do SQLite para o PostgreSQL. Por continuamente, quero dizer que reimportarei o banco de dados SQLite para o PostgreSQL todos os dias. Seria bom se eu pudesse fazer alterações nas tabelas no SQLite como bem entender, sem ter que fazer alterações manualmente no banco de dados PostgreSQL. Farei a migração do Python, mas pode ser qualquer ferramenta externa, que pode ser controlada a partir da linha de comando. A ferramenta precisa estar disponível para Linux, e seria bom se também rodasse no Windows.

Ao usar EXPLAIN, pode-se ver o custo de execução de uma consulta. O custo é em unidades artificiais, e são baseados em parâmetros pré-definidos. 1 é uma busca de disco e um ciclo de CPU é de 0,01 unidades, acredito. Minha pergunta é por que o PostgreSQL não executa automaticamente um teste na instalação para determinar os números reais com base no hardware? Não deveria ser uma óbvia vitória rápida?

Astor Data, Greenplum e GridSQL permitem processamento paralelo massivo de consultas SQL. Eles também são todos construídos em torno da tecnologia PostgreSQL. Isso é apenas devido a problemas de licenciamento ou há outros motivos? Para mim, parece que o MyISAM, não sendo compatível com ACID e, portanto, não tendo os mesmos problemas com o MVCC (como visto aqui ), pois o PostgreSQL é muito mais adequado para a construção de data warehouses de alto desempenho. Afinal, a carga OLAP não requer transações, tanto quanto posso ver.