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

Question

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

Есть столы: РАБОТНИК а также Emaillist.

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

2 таблицы соединены таким образом, чтобы, если один из сотрудников. Email1 или Officeee.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 который Варчар (256) из EMAILLIST Таблица индексируется. Теперь время отклика составляет 14 секунд.

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

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

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

Answer 1

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

Answer 2

Нет проблем, индексирующей столбец варчара как таковой

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

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

Answer 3

Попробуйте избавиться от части «или e2.email is null» в вашем запросе и посмотрите, как быстро он работает. Если он работает быстрее, вы сможете запустить его быстрее с помощью «Union All»