первое что нужно сделать это перестать тролировать и признать jsonc или какойнибудь python/js жсоном :3

проверять на валидность можно тут https://jsonlint.com/

?

[{ "a": ["foo1", "foo2"] }, { "b": ["boo1", "boo2"] }] вот такой жсон является валидным и возможно отвечает Вашим требованиям

спасибо, сейчас полезу все проверять и перезаливать

не может быть. чего-то нам не договариваете

{"0": {"8001": "1"}, "1": {"6832": "1"}, "2": {"9306": "2"}, "3": {"9316": "10"}, "4": {"9305": "2"}, "5": {"866": "1"}, "6": {"3102": "1"}}

вот строка

{"0": {"8001": "1"}, "1": {"6832": "1"}, "2": {"9306": "2"}, "3": {"9316": "10"}, "4": {"9305": "2"}, "5": {"866": "1"}, "6": {"3102": "1"}}

в этом всё норм

тогда повторю вопрос) как достать запись, зная, только "8001"

Можно ли сделать так, чтобы падение одного из процессов не валило всю базу? Сейчас получается, что один процесс падает и тащит за собой все остальные. Где логика? Где стабильность?

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

Одна мелкая ошибка валит базу. Честно говоря, не ожидал, что оно так

Логика в том, что у вас упавший процесс чего-то сделал с шареной памятью, и ПГ посчитал, что там каша (вполне обоснованно). Соответственно, перезапустился.

Одна мелкая ошибка валит базу. Честно говоря, не ожидал, что оно так

а что за ошибка вызывает сегфолт базы, в вашем случае?

а что за ошибка вызывает сегфолт базы, в вашем случае?

Похоже, память течёт

где?

где?

Пока не знаю. Будем воспроизводить и смотреть через gdb

Корка-то есть?

некоторые функции работы с JSON бывает изредка утягивают БД в сегфолт

(сталкивался в 9.3)

Логика в том, что у вас упавший процесс чего-то сделал с шареной памятью, и ПГ посчитал, что там каша (вполне обоснованно). Соответственно, перезапустился.

Доступ к shared memory всё равно же координируется? Процессы же не наугад в память пишут?

версия какая?

версия какая?

9.6.5

Fix crash due to rowtype mismatch in json{b}_populate_recordset() (Michael Paquier, Tom Lane) в 9.6.6 какие-то креши чинили

Fix crash due to rowtype mismatch in json{b}_populate_recordset() (Michael Paquier, Tom Lane) в 9.6.6 какие-то креши чинили

У нас oomkiller. Настолько привык, что в OracleDB крах процесса не влияет на остальные, что прямо удивительно. Просто прибиваешь процесс - и готова база.

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

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

Так не должны 50 процессов жрать много мегабайт. Work_mem 1 мб или около того

так а в упавшем запросе что?

так а в упавшем запросе что?

В запросах ничего особенного. Скорее всего, огребает непричастный.

work_mem не запрещает аллоцировать больше, постгрес на него смотрит только в процессе планирования

Work_mem в Посгресе это увы, просто пожелание трудящихся. Это та цифра, на которую оптимизатор ориентируется, планируя выполнение запроса. Типа сортировка будет использовать буфер на больше этго размера. Если оптимизатор сильно не ошибётся в статистике, то может выйти за эти пределы. Ну и нет никакого жёсткого ограничения на память. Если кому-то захочется сожрать её всю, то никакой work_mem этому не помешает.

Так что надо ловить разожравшиеся бэкенды, цепляться к ним отладчиком и дампить мемори контексты.

Так что надо ловить разожравшиеся бэкенды, цепляться к ним отладчиком и дампить мемори контексты.

Это и собираемся

Может быть по ним удасться понять кто съел память. А может и не удасться...

тогда повторю вопрос) как достать запись, зная, только "8001"

Какую запись нужно достать? т. е. какой будет результат?

Какую запись нужно достать? т. е. какой будет результат?

with t as (select * from (values(1, '{"0": {"8001": "1"}, "1": {"6832": "1"}, "2": {"9306": "2"}, "3": {"9316": "10"}, "4": {"9305": "2"}, "5": {"866": "1"}, "6": {"3102": "1"}}'::jsonb),(2,'[{"999":"test"}]'::jsonb)) as t(id,j)) select id, jsonb_pretty(j) from t; думаю тут нужно получить запись с id=1

если заранее известен уровень вложенности то видимо дойти до ключей 8001, 6832, 9306, ... не сложно.

если заранее известен уровень вложенности то видимо дойти до ключей 8001, 6832, 9306, ... не сложно.

Операторы есть для поиска ключа верхнего уровня, скорее всего реккурсивный обход нужен

Какую запись нужно достать? т. е. какой будет результат?

Json это поле в таблице, надо достать всю запись Надо типа поиск по значению (например 8001) При построении запроса он мне выводит все записи таблицы, не выбирает по значению

Мне нужен поиск внутри массива, не по верхнему значению

если заранее известен уровень вложенности то видимо дойти до ключей 8001, 6832, 9306, ... не сложно.

В том то и дело, что он не идёт туда((( Я не догоняю вообще как это работает

#report #spam @pasha_golub @Komzpa

В том то и дело, что он не идёт туда((( Я не догоняю вообще как это работает

Если есть функции работающие с верхним уровнем ключей то нужный уровень придется сделать таковым

всем доброго! подскажите пожалуйста как быть: - есть две таблицы products(товары), param_values(значения параметров товаров), и таблица их соединяющая param_values_products - param_values хранит значения (value) соответствующего параметра (param_name_id) - каким образом мне выбрать товары у которых различные параметры (param_name_id) принимают заданные значения, типа: (value >= 100 AND value <= 150 AND param_name_id = 45) AND (value >= 1 AND value <= 3 AND param_name_id = 14) вложенный селект не пойдет тк параметров(param_name_id) по сути не фиксированное и большое кол-во

https://www.postgresql.org/docs/9.4/static/queries-union.html

where .... and exists (select from params where id=product_id and param_value between 10 and 100) and exists (...)

всем доброго! подскажите пожалуйста как быть: - есть две таблицы products(товары), param_values(значения параметров товаров), и таблица их соединяющая param_values_products - param_values хранит значения (value) соответствующего параметра (param_name_id) - каким образом мне выбрать товары у которых различные параметры (param_name_id) принимают заданные значения, типа: (value >= 100 AND value <= 150 AND param_name_id = 45) AND (value >= 1 AND value <= 3 AND param_name_id = 14) вложенный селект не пойдет тк параметров(param_name_id) по сути не фиксированное и большое кол-во

SELECT p.* FROM param_values_products AS vp LEFT JOIN products AS p ON p.id=vp.product_id LEFT JOIN param_values AS pv ON pv.id=vp.values_id WHERE (pv.value >= 100 AND pv.value <= 150 AND vp.param_name_id = 45) UNION SELECT p.* FROM param_values_products AS vp LEFT JOIN products AS p ON p.id=vp.product_id LEFT JOIN param_values AS pv ON pv.id=vp.values_id WHERE (pv.value >= 3 AND pv.value <= 3 AND vp.param_name_id = 14) UNION ...

SELECT p.* FROM param_values_products AS vp LEFT JOIN products AS p ON p.id=vp.product_id LEFT JOIN param_values AS pv ON pv.id=vp.values_id WHERE (pv.value >= 100 AND pv.value <= 150 AND vp.param_name_id = 45) UNION SELECT p.* FROM param_values_products AS vp LEFT JOIN products AS p ON p.id=vp.product_id LEFT JOIN param_values AS pv ON pv.id=vp.values_id WHERE (pv.value >= 3 AND pv.value <= 3 AND vp.param_name_id = 14) UNION ...

План выполнения смотрели? Цену каждого селекта?

План выполнения смотрели? Цену каждого селекта?

А что не так, если join по ключам?

SELECT p.* FROM param_values_products AS vp LEFT JOIN products AS p ON p.id=vp.product_id LEFT JOIN param_values AS pv ON pv.id=vp.values_id WHERE (pv.value >= 100 AND pv.value <= 150 AND vp.param_name_id = 45) UNION SELECT p.* FROM param_values_products AS vp LEFT JOIN products AS p ON p.id=vp.product_id LEFT JOIN param_values AS pv ON pv.id=vp.values_id WHERE (pv.value >= 3 AND pv.value <= 3 AND vp.param_name_id = 14) UNION ...

а почему outer join если (pv.value >= 3 AND pv.value <= 3) ?)

А что не так, если join по ключам?

ну наверно то, что из за двойного left join оптимизатор не знает, сколько он достанет записей (pv.value >= A AND pv.value <= B) и вероетно будет seq scan ) но нужно смотреть план

тогда повторю вопрос) как достать запись, зная, только "8001"

where (json->'0'-»'8001') = '1' ??

тогда повторю вопрос) как достать запись, зная, только "8001"

можно так select * from ttt left join jsonb_each(json_field) as j on true where j.key = '8001'

Спасибо всем неравнодушным

Привет всем.

Pgsql9.6 Кто пользовался btrfs с компрессией для баз? Там проблемы могут быть какие? Есть альтернативы?

Компрессия для БАЗ? Вы чего, СЕРЬЁЗНО?

Ну там таблица в 100 гиг

Привет всем.

Кирилл, это ты?

Денег на диски не хватает?

Возможно он думает что процы дешевле.

Pgsql9.6 После того как я сделал cluster table как-нибудь можно контролировать сохранение упорядоченности?

Я бы понял ещё интеллектуальное сжатие данных ВНУТРИ БД, Типа columnstore и так далее. А СНАРУЖИ в ФАЙЛОВОЙ СИСТЕМЕ--- это треш какой-то.

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

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

Кэш ОС — вторая безумная затея из той же серии . Касательно БД, только.

А с кэшом ОС то что не так? )

А зачем он?

Память лишняя?

Впрочем, это всё сугубо теоретические споры и холивар, извините. Я просто удивляюсь подходам таким...

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

Это ты с MySQL прибежал с такими мыслями что ли ?

Зачастую - да, бывает лишняя. По сжатию http://garret.ru/PageLevelCompression.pdf , видимо в PgPro тоже достаточно безумные сидят

Не, такое сжатие как раз наоборот ОК

Я же выше сказал.

Это ты с MySQL прибежал с такими мыслями что ли ?

Причем тут MySQL?

Ну у MySQL нет собственного кэша данных на MyISAM, он использует кэширование ОС

*поперхнулся смузи*

*поперхнулся смузи*

Ты не пей такую гадость...

Ты не пей такую гадость...

лучше ты не кури вот это вот, что ты там куришь

Ну, PostgreSQL тоже использует кэширование данных ОС, и говорят, если его попробовать отключить, будет больно об этом вспоминать (лично не пробовал). ;)

Ну у MySQL нет собственного кэша данных на MyISAM, он использует кэширование ОС

PostgreSQL тоже с диском не в O_DIRECT работает, и ничего, жив. Там же всё немного сложнее чем прочто использует или нет

Зачастую - да, бывает лишняя. По сжатию http://garret.ru/PageLevelCompression.pdf , видимо в PgPro тоже достаточно безумные сидят

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

Pgsql9.6 После того как я сделал cluster table как-нибудь можно контролировать сохранение упорядоченности?

Насколько я помню это одноразово работает и потом просто периодически нужно запускать в зависмости от частоты изменений в таблице.

* ехидно ухмыляясь @funny_falcon а его хорошо потестировали? погоняли на различных типах нагрузки, на отказоустойчивость, и вот это фсйо?

*поперхнулся смузи*

Ну что поделаешь, не видели люди, что случается с мысклем, когда включается сжатие.

* ехидно ухмыляясь @funny_falcon а его хорошо потестировали? погоняли на различных типах нагрузки, на отказоустойчивость, и вот это фсйо?

да, мы уже больше чем полгода сегфолтов на нём не ловим

Ну что поделаешь, не видели люди, что случается с мысклем, когда включается сжатие.

а в innodb, между прочим, самое передовое сжатие из всех open-source субд. вот то, что ПгПро написало — это какой-то детский лепет по сравнению с тем, что в innodb

а в innodb, между прочим, самое передовое сжатие из всех open-source субд. вот то, что ПгПро написало — это какой-то детский лепет по сравнению с тем, что в innodb

??? И чем же оно такое передовое?

??? И чем же оно такое передовое?

чем грузины

??? И чем же оно такое передовое?

дизайном???

@Komzpa, я в курсе, что у вас оно давно уже более-менее стабильно работает, поэтому и уточнил, что на различных типах нагрузки, и на отказоустойчивость. Например, опердени в каком-нибудь банке?

??? И чем же оно такое передовое?

обкатанностью?

??? И чем же оно такое передовое?

Тем, что оно существенно снижает потребление ресурсов системы. Весьма существенно.