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

Question

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)

2 tables sont jointes de telle sorte que si l'une ou EMPLOYEE.EMAIL1 EMPLOYEE.EMAIL2 ne sont pas une 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

Colonne EMAIL qui est varchar (256) de la table de EMAILLIST est indexé. Maintenant, le temps de réponse est de 14 secondes.

Tableau des statistiques de comptage. À l'heure actuelle, EMPLOYÉ a obtenu 165,018 disques et Emaillist a obtenu 1,810,228 records, et les deux tables devraient croître à l'avenir

1. Est-ce une bonne idée / approche pour indexer une colonne VARCHAR? Cette question frappe immédiatement dans mon esprit à cause de la raison pour laquelle nous avons pas indexer une colonne VARCHAR avant dans notre application. Les experts conseils / suggestions à ce sujet sont très appréciés.
2. Avec cette requête en cours et de l'index, le temps de réponse de 14 secondes est raisonnable ou est-il une possibilité de réglage supplémentaire? Quels sont les autres expériences en temps réel de l'utilisateur / opinion basée sur ce genre de taille de la table et le temps de réponse?

Remarque: Mon cas exigence réelle / utilisation est expliquée en détail

Était-ce utile?

Nous faire parvenir

La solution

Il n'y a rien de mal avec l'indexation de la colonne varchar si vous allez faire des requêtes basées sur elle. Cependant s'il vous plaît garder à l'esprit qu'il y a des limites à certains indices et la façon dont ils peuvent indice beaucoup plus dans un seul champ. Exemple vous ne pouvez pas indexer une colonne qui peut contenir une quantité illimitée de texte. Cependant, vous devriez être en mesure de faire un index sur varchar (256) sans problème. Essayez et analyser les améliorations dans les performances de vos requêtes pour voir si elle aide.

Answer 1

Il n'y a rien de mal avec l'indexation de la colonne varchar si vous allez faire des requêtes basées sur elle. Cependant s'il vous plaît garder à l'esprit qu'il y a des limites à certains indices et la façon dont ils peuvent indice beaucoup plus dans un seul champ. Exemple vous ne pouvez pas indexer une colonne qui peut contenir une quantité illimitée de texte. Cependant, vous devriez être en mesure de faire un index sur varchar (256) sans problème. Essayez et analyser les améliorations dans les performances de vos requêtes pour voir si elle aide.

Answer 2

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

Où il peut devenir un problème est quand vous avez la colonne varchar comme FK dans une table milliards de ligne. Vous auriez alors une clé de substitution pour le PK et FK, mais vous auriez encore besoin d'une contrainte unique / index sur la touche varchar naturelle.

Vos tables sont assez petites et la performance pourrait être liée à la clause OR. Malheureusement, la même question se pose, peu importe la façon dont vous structurez la requête (et je ne suis pas assez familier avec PostgresSQL offrir beaucoup désolé)

Answer 3

Essayez de se débarrasser de la « OU e2.email IS NULL » partie de votre requête et voir à quelle vitesse il fonctionne. Si elle est plus rapide que vous pourrez peut-être exécuter plus rapidement avec une « union tous »