É uma boa ideia / abordagem indexar uma coluna VARCHAR?

Estamos usando o PostgreSQL v8.2.3.

Existem tabelas envolvidas: EMPREGADO e EMAILISTA .

Table 1: EMPLOYEE (column1, column2, email1, email2, column5, column6)
Table 2: EMAILLIST (email)

2 tabelas são unidas de 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 da contagem de tabelas: Atualmente, o EMPREGADO possui 165.018 registros e o EMAILLIST possui 1.810.228 registros, e espera-se que as duas tabelas cresçam no futuro.

1. É uma boa ideia / abordagem indexar uma coluna VARCHAR? Esta pergunta imediatamente me ocorreu pela razão de não termos indexado uma coluna VARCHAR antes em nosso aplicativo. Especialistas aconselhamento / sugestão sobre isso são muito apreciados.
2. Com essa consulta e índice atuais, o tempo de resposta de 14 segundos é razoável ou existe algum escopo 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 real / caso de uso é explicado em detalhes aqui .

Não há nada de errado em indexar uma coluna varchar se você estiver fazendo consultas com base nela. No entanto, lembre-se de que existem 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 no varchar (256) sem problemas. Experimente e analise as melhorias no desempenho de suas consultas para ver se isso ajuda.

Não há nenhum problema ao indexar uma coluna varchar como tal

O ponto em que isso pode se tornar um problema é quando você tem a coluna varchar como uma tabela FK em um bilhão de linhas. Você teria uma chave substituta para PK e FK, mas ainda precisaria de uma restrição / índice exclusivo na chave varchar natural.

Suas tabelas são muito pequenas e o desempenho pode estar relacionado à cláusula OR. Infelizmente, o mesmo problema se aplica, não importa como você estruture a consulta (e eu não estou familiarizado o suficiente com o PostgresSQL para me desculpar)

Tente se livrar da parte "OR e2.email IS NULL" da sua consulta e veja com que rapidez ela é executada. Se funcionar mais rápido, você poderá executá-lo mais rapidamente com uma "união de todos"