O Postgresql 9.4 permite ATUALIZAR visões materializadas CONCORRENTEMENTE , se elas tiverem um índice ÚNICO.
Estou procurando uma consulta SQL que liste todas as visualizações materializadas que NÃO possuem um índice UNIQUE ou PRIMARY KEY.
Estou criando um aplicativo da web para recuperar subconjuntos de uma tabela grande (4m linhas). As linhas de 4m mudam apenas uma vez por ano. A tabela tem mais de 200 colunas de tipos booleanos e numéricos. Não tem colunas de texto.
Os usuários consultarão subconjuntos desta tabela para download.
Estou bastante familiarizado com o banco de dados PostgreSQL 9.1 e meu plano é:
- O webapp ajudará o usuário a criar consultas como "WHERE a=3 AND b=true AND c>300"
- O banco de dados terá índices adequados para as colunas mais usadas.
AGORA .. Eu li aqui: https://stackoverflow.com/questions/10053050/why-is-solr-so-much-faster-than-postgres :
Recentemente, mudei do Postgres para o Solr e notei uma aceleração de aproximadamente 50x em nossas consultas. As consultas que executamos envolvem vários intervalos e nossos dados são listagens de veículos. Por exemplo: "Encontre todos os veículos com quilometragem < 50.000, $ 5.000 < preço < $ 10.000, marca=Mazda..."
Então, agora eu me pergunto: as pesquisas de Solr, Lucene, ElasticSearch e Amazon Cloud Search serão mais rápidas que o PostgreSQL, mesmo que nenhuma pesquisa de texto completo esteja envolvida?
Eu uso o PostgreSQL 9.2. Eu tenho uma tabela com aproximadamente 5 milhões de linhas e 150 colunas. A tabela não muda nada (eu a substituo uma vez por ano). Os usuários consultam esta tabela com todos os tipos de filtros em qualquer uma das colunas, por exemplo
select * from table where C > 43 and H is not null;
select * from table where A is null and F < 10 and F > 1 and X > 2;
Para desempenho, pretendo criar um índice em cada coluna da tabela. Um sentimento no estômago me diz para perguntar primeiro aos especialistas: é um bom design para o caso de uso descrito acima criar um índice em cada coluna?
ATUALIZAÇÃO: Tenho que especular sobre casos de uso reais. Ainda não consigo medir as consultas exatas. Isso está em fase de projeto.
O servidor está bem equipado com RAM e armazenamento SSD, então as consultas já são "rápidas" agora e posso sentir o efeito do cache quando aciono consultas semelhantes em sequência.
As colunas são dos tipos double, integer, timestamp e geometry (que explicitamente obtém um índice 'gist').
As consultas incluirão de 1 a 10 colunas. Normalmente ~6. Os resultados geralmente serão <20k linhas. As consultas em uma coluna nunca serão relacionadas a outra coluna.
Obrigado por todas as explicações. O que vou fazer: * selecionar 1/4 das colunas que acho que serão mais utilizadas e criar índices. * aguarde mais testes/uso e comece a medir/analisar as consultas e os casos de uso.
obrigada