Est-ce une bonne idée / approche d'indexer une colonne VARCHAR?

Nous utilisons PostgreSQL v8.2.3.

Il y a des tables impliquées: EMPLOYEE et EMAILLIST .

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

Deux tables sont jointes de manière à ce que si EMPLOYEE.EMAIL1 ou EMPLOYEE.EMAIL2 ne possède pas d'entrée correspondante, ces lignes sont renvoyées.

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

La colonne EMAILqui est varchar (256) de la EMAILLISTtable est indexée. Le temps de réponse est maintenant de 14 secondes.

Statistiques sur le nombre de tables: EMPLOYEE compte actuellement 165 018 enregistrements et EMAILLIST, 1 810 228 enregistrements, et les deux tableaux devraient augmenter à l'avenir.

1. Est-ce une bonne idée / approche d'indexer une colonne VARCHAR? Cette question me préoccupe immédiatement parce que nous n’avons jamais indexé une colonne VARCHAR dans notre application. Les avis / suggestions des experts à ce sujet sont très appréciés.
2. Avec cette requête et cet index actuels, le temps de réponse de 14 secondes est raisonnable ou existe-t-il une possibilité de réglage supplémentaire? Quelles sont l'expérience / l'opinion en temps réel d'autres utilisateurs basée sur ce type de taille de table et de temps de réponse?

REMARQUE: Mon besoin actuel / mon cas d'utilisation est expliqué en détail ici .

Il n'y a rien de mal à indexer une colonne varchar si vous allez effectuer des requêtes basées sur celle-ci. Cependant, gardez à l'esprit que certains index sont limités et combien ils peuvent indexer dans un seul champ. Exemple, vous ne pouvez pas indexer une colonne pouvant contenir une quantité illimitée de texte. Cependant, vous devriez pouvoir faire un index sur varchar (256) sans problème. Essayez-le et analysez les améliorations apportées aux performances de vos requêtes pour voir si cela peut vous aider.

Il n'y a pas de problème d'indexation d'une colonne varchar en tant que telle

Cela peut devenir un problème lorsque vous avez la colonne varchar comme FK dans une table de milliards de lignes. Vous auriez alors une clé de substitution pour les clés PK et FK, mais vous auriez toujours besoin d'un indicateur / contrainte unique sur la clé naturelle varchar.

Vos tables sont assez petites et la performance pourrait être liée à la clause OR. Malheureusement, le même problème s’applique quelle que soit la structure de la requête (et PostgresSQL n’est pas assez familier pour vous en excuser)

Essayez de vous débarrasser de la partie "OR e2.email IS NULL" de votre requête et de voir à quelle vitesse elle s'exécute. Si cela fonctionne plus vite, vous pourrez peut-être le faire plus rapidement avec un "union all"