Это хорошая идея / подход для индексации столбца VARCHAR?

Мы используем PostgreSQL v8.2.3.

Здесь задействованы таблицы: EMPLOYEE и EMAILLIST .

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

2 таблицы объединяются таким образом, что если EMPLOYEE.EMAIL1 или EMPLOYEE.EMAIL2 не имеют совпадающей записи, эти строки будут возвращены.

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

Колонка EMAILкоторый является VARCHAR (256) из EMAILLISTтаблицы индексируется. Теперь время отклика составляет 14 секунд.

Статистика подсчета таблиц: В настоящее время у EMPLOYEE есть 165 018 записей, а у EMAILLIST - 1 810 228 записей, и в будущем ожидается рост обеих таблиц.

1. Это хорошая идея / подход для индексации столбца VARCHAR? Этот вопрос сразу же приходит мне в голову из-за причины, по которой мы ранее не индексировали столбец VARCHAR в нашем приложении. Совет экспертов / предложения по этому вопросу высоко ценятся.
2. С этим текущим запросом и индексом время отклика 14 секунд является разумным или есть ли возможность для дальнейшей настройки? Каков опыт / мнение другого пользователя в зависимости от размера таблицы и времени ответа?

ПРИМЕЧАНИЕ. Мои действительные требования / варианты использования подробно описаны здесь .

Нет ничего плохого в индексации столбца varchar, если вы собираетесь выполнять запросы на его основе. Однако имейте в виду, что существуют ограничения для некоторых индексов и того, сколько они могут индексировать в одном поле. Например, вы не можете индексировать столбец, который может содержать неограниченное количество текста. Однако вы должны быть в состоянии сделать индекс на varchar (256) без проблем. Попробуйте и проанализируйте улучшения в производительности ваших запросов, чтобы увидеть, помогает ли это.

Нет проблем с индексацией столбца varchar как такового

Проблема может возникнуть, когда у вас есть столбец varchar в виде FK в таблице с миллиардами строк. Тогда у вас будет суррогатный ключ для PK и FK, но вам все равно понадобится уникальное ограничение / индекс для естественного ключа varchar.

Ваши таблицы довольно малы, и производительность может быть связана с предложением OR. К сожалению, одна и та же проблема применяется независимо от того, как вы структурируете запрос (и я недостаточно знаком с PostgresSQL, чтобы извиниться)

Попробуйте избавиться от части запроса «OR e2.email IS NULL» и посмотрите, насколько быстро он выполняется. Если он работает быстрее, вы можете запустить его быстрее с «объединением всех»