возможно так херово делать ?

я вешал gist вроде, или как-то так, в общем не запомнил, так как поставил postgres чтобы поиграться. нагенерировал 3 млн. товаров с фильтрами по json, и вот на интах фильтры не работали увы. тут вопрос вот в чем, допустим я хочу добавить в фильтр значение новое: "Емкость батареи mAh", после этого нужно идти и создавать индекс? Если бы был индекс по всем полям JSON, включая числовые, индекс бы сам перестроился - удобно же.

BTREE индекс ты явно указываешь .

GIN, GIST если не ошибаюсь по всем ключам работают.... я не могу сейчас в документацию залезть посмотреть .....

но суть вот какая что GIN, GIST работают только по нескольким операторам и не работаю с такими операторами как ">", "<" и так далее

могу ошибаться конечно просто сейчас не могу посмотреть инфу ?

я вешал gist вроде, или как-то так, в общем не запомнил, так как поставил postgres чтобы поиграться. нагенерировал 3 млн. товаров с фильтрами по json, и вот на интах фильтры не работали увы. тут вопрос вот в чем, допустим я хочу добавить в фильтр значение новое: "Емкость батареи mAh", после этого нужно идти и создавать индекс? Если бы был индекс по всем полям JSON, включая числовые, индекс бы сам перестроился - удобно же.

Даже если бы они работали, всё это индексирование в стиле "авось повезёт", IMHO. А Вам это зачем?

фильтры каталога

товары и прочее.

чтобы не делать EAV

А нормализованную модель нельзя сделать? Всё равно с EAV и аналогами Вы будете страдать, хотя с аналогами поменьше. :(

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

или как?

я знаю пока три способа организации фильтров: - EAV - JSONB - прямо в табличке рядом хранить - ну и оставшиеся варианты с битовыми масками Redis и прочим, но основных все же три

. Flat table (т.е. в той же (соседней / по группам) таблице NULL-able поля). . Отдельная таблица для каждого.

JSON удобней, так как просто суешь свойство в объект, и попутно суешь свойство в глобальный объект свойств. Конечно, целостность сложно поддерживать, но лучше чем таблица на каждое свойство. Хотя пристально не рассматривал данный вариант, может и не плох в целом.

JSON удобней, так как просто суешь свойство в объект, и попутно суешь свойство в глобальный объект свойств. Конечно, целостность сложно поддерживать, но лучше чем таблица на каждое свойство. Хотя пристально не рассматривал данный вариант, может и не плох в целом.

Насколько сильно с JSON(b) придётся мучаться, зависит от запросов (потребностей в поиске по нему) и распределения этих самых свойств. И поддержание ссылочной целостности — это тоже много.

И ещё зависит от количества этих свойств товаров, и того, как часто добавляются новые, конечно.

всё норм индексируется, все ключи сразу

чо вы тут устроили «я проверял но не помню»

всё норм индексируется, все ключи сразу

Да, но отсутствие статистики для индексированного JSONB — это совсем не "норм". Это значит, что планы строятся фактически наугад. :(

jsquery юзать

если план говно, пиши в пгпро

всё норм индексируется, все ключи сразу

https://toster.ru/q/487618

вот я задавал вопрос 11 декабря

с того момента что-то разве изменилось?

если план говно, пиши в пгпро

С какой целью? Т.е. чем это поможет?

с того момента что-то разве изменилось?

Ну а разве там не нормальный ответ?

проблема вот в чем, когда ты пишешь например features->>'brand' = 'Samsung' выполняется мгновенно. когда пишешь features->>battery = 3000 то уже долго.

это проблема плана или селективности и доступа к страничкам?

а чего может быть зависон INFO: wait for WAL segment /postgre/back/wal/rshn/00000001000000010000002C to be archived ?

висит так 5 минут и отваливается

это probackup

ERROR: switched WAL segment 00000001000000010000002C could not be archived in 300 seconds LOG: Backup is running, update its status to ERROR

проблема вот в чем, когда ты пишешь например features->>'brand' = 'Samsung' выполняется мгновенно. когда пишешь features->>battery = 3000 то уже долго.

С какими индексами? А EXPLAIN-ы Вы показывали?

там есть SQL Fiddle, но в нем мало строк, может индекс вообще не будет юзаться. у меня где-то был генератор товаров на PostgreSQL

про зависон вопрос отпал, решение простое было, PATH указать для pg_probackup и рестарт бд

там есть SQL Fiddle, но в нем мало строк, может индекс вообще не будет юзаться. у меня где-то был генератор товаров на PostgreSQL

Причём здесь SQL Fiddle с тремя записями?! Там и GIN-индекса-то нет, кстати. ;) Планы на реальных данных, индексах, запросах есть?

Причём здесь SQL Fiddle с тремя записями?! Там и GIN-индекса-то нет, кстати. ;) Планы на реальных данных, индексах, запросах есть?

Планы были когда я задавал вопрос на тостере. Сейчас запущу генератор товаров, и покажу в чем суть.

а не, не запущу. нету у меня того пакета который json генерирует. тут просто рандом с картинками ценами и т.д.

Планы были когда я задавал вопрос на тостере. Сейчас запущу генератор товаров, и покажу в чем суть.

И самих запросов, которые работают быстро, на тостере тоже нет... какие там условия были?

хочу странного: каким образом одно и то же значаение из таблицы вернуть в двух "столбца" типа select some_long_func(A) AS result, some_long_func(A) AS value FROM bigtable

два раза ведь будет считаться some_long_func?

каким образом можно вернуть результат some_long_func(A) в "двух полях" - result и value, но высчитывая это значение один раз

И самих запросов, которые работают быстро, на тостере тоже нет... какие там условия были?

SELECT * FROM products WHERE (features-»'weight')::int < 20 AND features @> '{"color": ["red"]}' ORDER BY (features-»'weight')::int DESC LIMIT 100;

QUERY PLAN ----------------------------------------------------------------------------------------------------------------------- Limit (cost=8889.20..8889.35 rows=60 width=212) -> Sort (cost=8889.20..8889.35 rows=60 width=212) Sort Key: (((features ->> 'weight'::text))::integer) DESC -> Seq Scan on products (cost=0.00..8887.43 rows=60 width=212) Filter: ((features @> '{"color": ["red"]}'::jsonb) AND (((features ->> 'weight'::text))::integer < 20)) (5 rows)

в таблице 179к строк

запрос за 63 мс.

здесь используются индексы?

сейчас индекс BTREE вроде

одну секунду. гляну

"products_features_idx" btree (features)

ну надеюсь ты сам себе на всё ответил

начиная с 63мс

и 60 строк

пока не особо, если честно. я не очень умею читать query plan у постгрес

я ж говорю, ставил чтобы поиграться.

я не могу сейчас воспроизвести ту проблему

возможно я без where запрос запускал

но прямо вот заметно дольше запрос думал, когда с числом начинал работать

ну и человек в том вопросе ответил как-то не однозначно, Больше возможностей внятно индексировать jsonb для запросов на числовые диапазоны мне как-то не вспоминается.

почитай пожалуйста про jsquery и индексную поддержку его диалекта

запрос который ты приводишь не покрывается btree индексом

и печально покрывается gin тоже

на тему жсона и индексов к нему реально нет специалистов лучше пгпро

спасибо, почитаю

поэтому если что, к ним

жесть

спасибо, почитаю

Да ещё учти что при использовании гин гист ничего не сортируй иначе иначе пг вытащит все данные которые нашёл и уже будет их сортировать

Да ещё учти что при использовании гин гист ничего не сортируй иначе иначе пг вытащит все данные которые нашёл и уже будет их сортировать

эм, можно пример с планом?

эм, можно пример с планом?

Order by разве работает по gin индексу?

Или по гист

по гист работает и даже ускоряет

в gin глубоко не копал, за гист зуб даю :)

Доеду до офиса проверю ещё раз.

просто, может, у тебя по твоему выражению сортировки лишний btree подхватился

здесь используются индексы?

Нет, не используются совсем. И GIN вообще не может быть использован в этом запросе, см.: https://www.postgresql.org/docs/current/static/datatype-json.html#JSON-INDEXING

ну и человек в том вопросе ответил как-то не однозначно, Больше возможностей внятно индексировать jsonb для запросов на числовые диапазоны мне как-то не вспоминается.

А для запросов типа "x-»a > const" в самом деле лучше всего создать соответствующие btree-индексы, IMHO.

@Komzpa create table if not exists test ( a text ); CREATE INDEX foo_idx ON test USING GIST (a); EXPLAIN ANALYZE SELECT * FROM test ORDER BY a DESC LIMIT 100; QUERY PLAN Limit (cost=26322.69..26322.94 rows=100 width=32) (actual time=4343.751..4344.697 rows=100 loops=1) -> Sort (cost=26322.69..27572.69 rows=500001 width=32) (actual time=4343.740..4344.056 rows=100 loops=1) Sort Key: a DESC Sort Method: top-N heapsort Memory: 34kB -> Seq Scan on test (cost=0.00..7213.01 rows=500001 width=32) (actual time=0.020..2113.605 rows=500001 loops=1) Planning time: 0.085 ms Execution time: 4345.048 ms

вставил бы скриншот но прав не имею таких ?

в таблице 100000 записей числа от 0 до 99999

ну в виде текста естественно

В таблице 500001 запись

А гистовый опкласс которую часть запроса обещал ускорять?

да я наврал

извини

не понял вопрос

гист должен ускорить поиск по значению

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