Из любви к изобретению велосипедов.

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

Всем привет ..
прошу помощи
выполняю перевод монгоДБ в постгрес .. и часто сталкиваюсь с вопросом перепаковки JSON в таблицы и на промежуточном этапе делаю десериализацию объектов
select string_agg('t.->>''' || t._key || ''' '|| t._key, ', ') from (select distinct jsonb_object_keys('{"text":false}'::jsonb) _key)t
хочу сделать ф-цию которая бы мне пробегалась по всем вложенностям и паковала пути типа
'root'->>'lvl1'#>'{0}'
и так далее

пробую собрать через with recursive но пока чето не могу придумать
может у кого есть подобный код .. ?

Есть утилитка mosql. Для миграции с монги в постгрес

сама миграция не интересна ..
миграцию подвязали на Mongo ChangeStream service и все что в монге летит в виде JSON
но спасиб опочитаю

Кто смотрел вчерашний Postgres-вторник? Там была там тема про auto_explain.analyze. В документации написано обтекаемо - "может катастрофически влиять на перформанс". Кто знает / где почитать, насколько сильно влияет ? Оно "просто" доп. данные по всем этапам выполнения запроса собирает (и overhead предположу будет <30%) ?

Одна известная postgres-компания после аудита на моем проекте советовала включить на проде auto_explain.analyze, наверно они понимали последствия и они не сильно катастрофические должны быть (но делать тогда это почему-то не стали)

Для начала — в документации, как всегда:
https://www.postgresql.org/docs/current/using-explain.html#USING-EXPLAIN-CAVEATS
https://www.postgresql.org/docs/current/sql-explain.html (Notes)

> но "просто" доп. данные по всем этапам выполнения запроса собирает (и overhead предположу будет <30%) ?

А может быть и более 600%. Это зависит от OS, её настроек, и самого запроса. См. ссылки выше, опять-таки.

как всегда, спасибо, пошел читать 🙂

Народ просветите есть ли способы кластеризовать постгрес? или все так же печально ?

gettimeofday - понятно, зависит от системы, в идеале незначительно (чем больше маленьких операций, тем больше измерений и больше оверхед?)

the current implementation of EXPLAIN ANALYZE adds profiling overhead to query execution

- то есть в идеале это все-таки проценты или десятки процентов

Хотим сделать запросы через процедуры к postgкуSQL, как это лучше сделать?
Не падает ли производительность от того, что написан в процедуре?
Кешируется ли план запроса для процедуры? Кешируется ли для sql-запроса? Что быстрее?
Если не процедура, то что использовать для выполнения запроса?

> Хотим сделать запросы через процедуры к postgкуSQL, как это лучше сделать?
Зависит от цели .. но в целом хранимые процедуры это правильно еще и с позиции безопастности данных
- как делать .. берете поинт который вызывает запрос и переписываете его в DML, из плюсов вы работаете с данными на уровне данных.. из рекомендаций старайтесь исключать секции with ну и если JOIN с большими таблицами то тоже переводите на саб-селект
> Не падает ли производительность от того, что написан в процедуре?
>Кешируется ли план запроса для процедуры? Кешируется ли для sql-запроса? Что быстрее?
Если ву делаете запрос типа _SQL = 'select * from '||склейка запросов и после execute то кеширования нет .. если же тупенько execute query select то кеширование работкает, нет производительность не падает
> Если не процедура, то что использовать для выполнения запроса?
вьюхи и мат-вьюхи

Обычно время выполнения запроса, показываемое explain analyze почти не отличается от времени выполнения запроса без него. gettimeofday в большинстве систем реализован  достаточно эффективно и не требует system call-а.  Так что разница не должна превышать единиц процентов. Мне казалось, что негативный эффект на скорость работы от включённого  auto_explain  скорее будет связан с значительным  увеличением объёма записи в лог файл. Но это почти  не зависит от того включён ли analyze или нет.

мне всегда хватало нескольких скриптов
один из которіх анализирует разницу между seq_scan и idx_scan чем показывает где пропущен индекс
и второй аналирует сколько раз были использованы индексы .. и нет ли лишних индексов в сестеме ..

Процедуры обычно позволяют значительно увеличить производительность работы.
Обычно разработчики в борьбе за скорость движутся по траектории ORM->SQL->PLpgSQL.
Те. сначала приложение работает с базой посредством какого-то ORM, потом критичные места переписываются на прямые SQLщапросы, если же и это не помогает, то пишут серверную процедуру. С процедурами основная проблема заключается в отладке и поддержке.

На простых запросах узким местом сейчас становится кана связи между клиентов и сервером. Т.е. 100% загрузить современный мощный сервер простыми  OLTP запросами не так то просто: мы упрёмся в сетку и систем каллы, а не в производительность базы. В этом отношении - stored procedures, которые могут запустить сразу много запросов на стороне сервера - это путь преодоления этого бутылочного горлышка.

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

> понятно, зависит от системы, в идеале незначительно

Да, в идеале. Но почему Вы думаете, что конкретный сервер "идеален" (для этого по ссылке и описана утилита для тестирования)? ;)

> чем больше маленьких операций, тем больше измерений и больше оверхед

Да. Насколько я помню, gettimeofday вызывается дважды для каждого tuple, проходящего через plan node.

> - то есть в идеале это все-таки проценты или десятки процентов

Если у Вас сплошь seq.scans узких таблиц, где много rows — может быть и куда больше.
Вот пример, на первой попавшейся таблице:

seq.scan таблицы с pg_column_size = 36, 10000000 rows:
COUNT(*): Time: 442,860 ms
EXPLAIN (ANALYZE) COUNT(*): Execution Time: 835.380 ms