Estamos usando o PostgreSQL v8.2.3.
Existem tabelas envolvidas: EMPLOYEE e EMAILLIST .
Table 1: EMPLOYEE (column1, column2, email1, email2, column5, column6)
Table 2: EMAILLIST (email)
2 tabelas são unidas de tal forma que, se EMPLOYEE.EMAIL1 ou EMPLOYEE.EMAIL2 não tiverem uma entrada correspondente, essas linhas serão retornadas.
SELECT employee.email1, employee.email2,
e1.email IS NOT NULL AS email1_matched, e2.email IS NOT NULL AS email2_matched
FROM employee
LEFT JOIN emaillist e1 ON e1.email = employee.email1
LEFT JOIN emaillist e2 ON e2.email = employee.email2
WHERE e1.email IS NULL OR e2.email IS NULL
A coluna EMAILque é varchar(256) da EMAILLISTtabela é indexada. Agora, o tempo de resposta é de 14 segundos.
Estatísticas de contagem de tabelas: Atualmente, EMPLOYEE tem 165.018 registros e EMAILLIST tem 1.810.228 registros, e espera-se que ambas as tabelas cresçam no futuro.
- É uma boa ideia/abordagem indexar uma coluna VARCHAR? Esta questão imediatamente me veio à mente devido ao motivo pelo qual não indexamos uma coluna VARCHAR antes em nosso aplicativo. Os conselhos/sugestões de especialistas sobre isso são muito apreciados.
- Com essa consulta e índice atuais, o tempo de resposta de 14 segundos é razoável ou há espaço para ajustes adicionais? Quais são as experiências/opiniões em tempo real de outros usuários com base nesse tipo de tamanho de tabela e tempo de resposta?
NOTA: Meu requisito/caso de uso real é explicado em detalhes aqui .
Não há nada de errado em indexar uma coluna varchar se você for fazer consultas com base nela. No entanto, lembre-se de que há limites para alguns índices e quanto eles podem indexar em um único campo. Exemplo, você não pode indexar uma coluna que pode conter uma quantidade ilimitada de texto. No entanto, você deve conseguir fazer um índice em varchar(256) sem problemas. Experimente e analise as melhorias no desempenho de suas consultas para ver se isso ajuda.
Não há problema em indexar uma coluna varchar como tal
Onde isso pode se tornar um problema é quando você tem a coluna varchar como um FK em uma tabela de bilhões de linhas. Você teria então uma chave substituta para o PK e FK, mas ainda precisaria de uma restrição/índice exclusivo na chave varchar natural.
Suas tabelas são bem pequenas e o desempenho pode estar relacionado à cláusula OR. Infelizmente, o mesmo problema se aplica independentemente de como você estrutura a consulta (e não estou familiarizado o suficiente com o PostgresSQL para oferecer desculpas)
Tente se livrar da parte "OR e2.email IS NULL" da sua consulta e veja a rapidez com que ela é executada. Se for mais rápido, você poderá executá-lo mais rapidamente com uma "união de todos"