Comments 10
Полезный тест. Проблема в том, что сейчас не так то просто отказаться от json. Например, его использую в качестве неструктурированного EAV для каталога (правда каталог не большой < 10 тыс). Как всегда, надо тестировать заранее на больших данных - без этого никуда!
А не надо от него отказываться. :) Он может быть полезен. И поскольку веб программисты очень часто используют json для своих собственных нужд удобно хранить данные тоже в json, чтобы не заморачиваться преобразованиями туда-сюда. Но если по каким-то полям json происходят частые запросы, тогда их имеет смысл оптимизировать. Например создавая специальные индексы для поиска по этим полям или, например, выносить их в таблицу в виде вычисляемого поля или еще как. Небольшие json работают не так уж плохо, никто не жаловался. :) Проблемные json обычно очень длинные.
Как вариант, для фильтруемых полей создавать сохраняемые вычисляемые столбцы, которые берут значения из json столбца.
Да, неплохой вариант, я забыл его упомянуть. Единственный его недостаток, что приходит в голову, то что эта функциональность появилась относительно недавно, а с проблемами сталкивался и в более старых версиях, где этой функциональности нет. Там помогает создание индекса по вычисляемому значению типа:
create index on test((j->>1));
Полезная статья, спасибо. Я сталкивался с подобным, но без jsonb и gin, а с "обычными" колонками - в какой-то момент планировщик переключился с btree по user_id на относительно недавно созданный btree created_at
Ну смотри, тут надо разбираться, почему так произошло. Первое что мне пришло бы в голову проверить, это при каких user_id такое происходит. Например, я сталкивался с ситуацией, когда планировщик отказывался от использования индекса, если значение находилось среди most_common_vals, но использовал индекс для поиска для всех остальных значений.
https://commitfest.postgresql.org/26/2071/ Скорее всего.
Вывод: обновляйте ваши постгресы, друзья мои!
Jsonb и gin, ошибки планировщика на старых PostgreSQL