LINUX.ORG.RU

Индексация JSONB в PostgreSQL для timestamp

 ,


0

1

Есть некая таблица хранящая JSONB в котором есть примерно следующие значения:

{
  "time": {
    "start": "2020-09-11T21:31:04Z"
    "end": "2020-09-11T21:44:10Z",
  }
}

И хочется их проиндексировать для ускорения поиска.

Но вот дело в том, что в строке хранится по сути «timestamp with timezone», а на него постгря ругается:

CREATE INDEX gen_time_index ON item (((data->'time'->>'start')::timestamp));

ERROR: ОШИБКА:  функции в индексном выражении должны быть помечены как IMMUTABLE

SQL state: 42P17

Как бы это можно было бы обойти?

Да, можно конечно завести отдельную таблицу/поле с типом timestamp и триггером заполнять. Но хотелось бы без лишних телодвижений.

★★★★★

Последнее исправление: WatchCat (всего исправлений: 2)

Ответ на: комментарий от no-such-file

Ок, спасибо.

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

WatchCat ★★★★★
() автор топика

Да, можно конечно завести отдельную таблицу/поле с типом timestamp и триггером заполнять. Но хотелось бы без лишних телодвижений.

Мда, создай колонки time_start и time_end с нужным типом, json вообще выкинь, он бесполезен для базы. Где нужно вебу отдать json генери его на лету.

firkax ★★★★★
()
Последнее исправление: firkax (всего исправлений: 2)

Не делай так. Идекс по json полю плохая затея. Сделай отдельную колонку timestamp

Aswed ★★★★★
()
Ответ на: комментарий от firkax

Почему бесполезен? Если мне прислали какой-то кусок, который в принципе неважен, а там такая простыня, которую нормализовать просто лень, а отдавать нужно. Почему бы и не сохранить сразу?

cdshines ★★★★★
()
Ответ на: комментарий от cdshines

Проблемы производительности как минимум. Ибо будет парсится сложная структура на insert/update что бы индекс перестроить. Кроме того, что будет с индексом если ты решишь поменять структуру json?

Aswed ★★★★★
()
Ответ на: комментарий от cdshines

Если бы он был не важен то его не потребовалось бы индексировать (автор спрашивает как индекс навесить).

которую нормализовать просто лень

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

А так, если это и правда просто блоб-строка которую принял-отдал то можно и json'ом хранить (если так быстрее чем конвертировать туда-сюда), но от базы никакой спец-поддержки для такого не нужно. Кстати, если конвертировать блоб-строку в экономный формат - то лучше делать это в воркере приложения а не в движке базы - потому как вычислительная мощность воркеров заметно проще масштабируется (просто добавить железа) чем базы.

firkax ★★★★★
()
Последнее исправление: firkax (всего исправлений: 1)
Ответ на: комментарий от cdshines

Бенчмарк чего? Того факта, что скорость работы базы нельзя удвоить (в отличие от приложения), просто поставив рядом ещё один такой же сервер?

firkax ★★★★★
()
Последнее исправление: firkax (всего исправлений: 1)
Ответ на: комментарий от cdshines

Не знаю, не интересовался никогда таким. Можешь сам провести, думаю это не сложно. Но «порядок разницы» будет заметно зависеть от сопутствующих обстоятельств. И думаю колоночную структуру не просто так придумали, давай вообще колонки отменим и оставим индексированный список json-ов, раз разницы нет?

firkax ★★★★★
()
Ответ на: комментарий от firkax

Сначала придумали одну структуру, потом добавили другую, все логично :) Если аргумент «не знаю, было так, а стало не так» - все, что есть, то, вероятно, прислушиваться к нему стоит с опаской.

cdshines ★★★★★
()
Ответ на: комментарий от cdshines

Ну, если для тебя это выглядит так - не прислушивайся. Веб и так заполнен помойкой, от того что лично ты туда что-то ещё добавишь мне мало что поменяется.

firkax ★★★★★
()
Ответ на: комментарий от cdshines

не знаю, как счас, в 9.4 был в разы медленнее индекса по полю.

Shadow ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.