Всем привет. У меня есть таблица: CREATE TABLE (docid integer, attrs

jsonb);
где в attrs представляет собой:
{...
dates: ["2020-10-01", "2021-02-01"],
...
}
Такой запрос позволяет отобрать записи, старше 2020-10-02, но по плану исполнения запрос скатывается в SeqScan:
SELECT attrs FROM document_resinfo WHERE attrs @? '$.dates[*].datetime() ? (@ >= "2020-10-02".datetime())';

Вопрос: можно ли создать индекс по полю attrs, чтобы он работал в запросах подобного вида?

а сейчас индекс есть, план запроса? Из вас все клещами надо тянуть? https://postgrespro.ru/docs/postgresql/14/datatype-json 8.14.4

EXPLAIN ANALYZE SELECT docid FROM document_resinfo WHERE attrs @? '$.odates[*].datetime() ? (@ >= "2020-10-02".datetime())'; QUERY PLAN ------------------------------------------------------------------------------------------------------------------- Seq Scan on test (cost=0.00..3784.12 rows=734 width=4) (actual time=39.792..47.341 rows=934 loops=1) Filter: (attrs @? '$."dates"[*].datetime()?(@ >= "2020-10-02".datetime())'::jsonpath) Rows Removed by Filter: 17236 Planning Time: 0.626 ms Execution Time: 47.406 ms (5 строк

индекс сейчас есть или нет по полю JSONB? Если есть какой?

Индекс пробовал создавать: CREATE INDEX test_idx ON test USING GIN (attrs jsonb_path_ops); CREATE INDEX test_idx ON document_resinfo USING GIN (attrs);

Не помогло

пиши даты в обычные поля. зачем этот json тут?

у вас здесь идет преобразование типов, обычные индексы так не работают.

Ровно в таком — не факт, если по смыслу в таком — то можно сделать функцыональный индэкс на оператор, который вытягивает min(dates).

модно, стильно, молодежно

а потом еще один, и еще один, проще преобразовать и хранить в int виде и все будет работать

ну тогда в чем вопрос? этого всего же вы достигли, а на использование индекса можно закрыть глаза

я не автор вопроса. :)

пардон :)

Именно требуется произвести поиск записей по агрегированному условию по дат. Поскольку в jsonpath есть операторы datetime(), стало интересно, можно ли как-то это использовать.

смотрел доклад Бартунова последний по JSONB, с оптимизацией TOAST, понравилась в конце фраза, что используя JSONB в таблице, делайте хотя бы doc_id вне json. :)

вы и без json в обычных плоских данных to_timestamp получите тот же результат измените тип хранения и будет счастье.

зачем вы навалили все в кучу **** и потом там роетесь? логично сделать нормальную структуру таблицы

Возможно вам вообще стоит хранить их как нормальные человеческие диапазоны https://postgrespro.ru/docs/postgresql/14/rangetypes#RANGETYPES-BUILTIN