Я бы настоятельно рекомендовал нормализовать структуру вашей таблицы.
Участники должны перейти в отдельную таблицу с колонками id_conversation и id_user.Это было бы лучше для поиска и обновления, чем использование массива (json).
То же самое с messages.Почему бы не хранить их в отдельной таблице со столбцами id_conversation, timestamp, id_user, message_text?Это было бы гораздо лучше для поиска и обновления.И это делает вашу таблицу разговоров намного меньше.
В добавление : Для чего этот столбец participants?Если у вас есть сообщения для каждого разговора, вы можете легко запросить в таблице всех пользователей, которые отправили сообщение в разговор, например,
SELECT DISTINCT id_user FROM messages WHERE id_conversation = 42
Редактировать :
Принципиально: наборы данных 1M - это много, но не гигантская таблица.У Postgres с хорошим дизайном стола проблем не должно быть.Но я предполагаю, что в одном разговоре гораздо меньше сообщений, поэтому вы можете многое сделать с фильтрацией и индексацией.
1.Я настоятельно рекомендую подумать о некоторых умных индексах для ваших таблиц, которые должны сделать поиск действительно быстрым.Может быть, поможет индекс по временным меткам сообщения и один по идентификаторам конверсии:
CREATE INDEX idx_messages_timestamp
ON messages (timestamp);
CREATE INDEX idx_messages_conversations
ON messages (id_conversation);
Если вы хотите получить новые сообщения, может быть полезно создать индексы с порядком DESC (... ON messages(... DESC))
2.Для действительно огромных таблиц (я имею в виду ДЕЙСТВИТЕЛЬНО огромные таблицы) может быть полезно разбить на него.Это разбивает вашу таблицу внутри по определенному критерию - возможно, по метке времени (например, ежемесячно или ежегодно).Так что если вы в основном выбираете более новые данные, старые будут заархивированы в отдельных таблицах внутри.Таким образом, запрос находится только в строках запрошенной таблицы меньшего размера.
Но это своего рода продвинутый : https://www.postgresql.org/docs/current/static/ddl-partitioning.html