Следует ли использовать составной первичный ключ для ускорения выбора на основе отметки времени в PostgreSQL?

Question

У меня есть таблица worker_activity_events в PostgreSQL 11:

• column1: worker_id integer not null
• column2: created_at timestamp default now() not null
• column3: event_type text

Каждая запись должна иметь worker_id и created_at. Часто задаваемый запрос:

SELECT * FROM worker_activity_events
WHERE worker_id = $1
  AND created_at BETWEEN $2 AND $3

Для быстрого выполнения запроса целесообразно добавить PRIMARY KEY(worker_id, created_at)?

Может возникнуть проблема: при выборке отметки времени 2 генерируются события одного и того же работника, а второй будет отклонен из-за нарушения первичного ключа (worker_id, creation_at). Допустим, в моем приложении я могу предотвратить это.

Answer 1

Каким был бы первичный ключ, если бы не это соображение?

Вы можете создать составной индекс для (worker_id, created_at). Нет причин объявлять его первичным ключом, просто чтобы получить его в качестве индекса.

Но вы также можете создать индекс или, возможно, даже первичный ключ для (worker_id, created_at, event_type). Этот индекс должен уметь делать все, что может другой, и даже больше. Если event_type не очень широк, он не должен быть намного больше. Недостатком является то, что если вы обновите строки, чтобы изменить только event_type (что не очень вероятно, только на основе имен столбцов), этот индекс отключит оптимизацию Heap-Only-Tuple.

Answer 2

С точки зрения теории баз данных, я бы сказал, что вы должны определить первичный ключ на основе того, что действительно идентифицирует строку, а не исходя из соображений производительности.

Так что, если нет естественного первичного ключа, определите искусственный и используйте CREATE INDEX для создания индекса, необходимого для запроса.

Однако в реальной жизни иногда приходится отклоняться от теоретического идеала. Если из соображений производительности требуется, чтобы у вас было как можно меньше индексов, и вы можете использовать первичный ключ, который вы предлагаете, go для него. В противном случае придерживайтесь теории - преждевременная оптимизация - это root всего зла.