простите. а как именно мониторить именно причину чекпойнта? SELECT * FROM pg_stat_bgwriter; ничего внятного не показывает в какие метрики смотреть?

Надо бы мат-часть подтянуть. https://www.youtube.com/watch?v=Asicqi0ewO8

Привет всем, нужен совет. Есть таблица вида create table info(patid integer, stamp timestamptz, fullname text, constraint test_pk primary key (patid, stamp)); create index info_trgm_idx on info using gin (fullname);где лежат разные временные версии пациента. Это сделано для возможности иметь полную картину на произвольный срез времени и архивного поиска. Я бы хотел при поиске подстроки в fullname иметь возможность отобрать первые N уникальных пациентов, а не строк. То есть я не могу написать select * from info where fullname ~* 'смирнов дени' limit 10;так как не знаю, сколько найдется Денисов и сколько у каждого из них версий. Я могу вначале выбрать все результаты, а потом отрезать нужное количество... но вопрос именно в том, можно ли ускорить выборку аналогом limit для такой схемы хранения. Чтобы по мере нахождения новых строк считалось уникальное количество пациентов в pipeline mode и достигнув предела запрос прекращался.

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

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

оконные функции в pg требуют вначале вытащить все данные и проагрегировать их, никакого piplene mode тут не получится((

оконные функции в pg требуют вначале вытащить все данные и проагрегировать их, никакого piplene mode тут не получится((

Заведите флаг is_actual и сделайте по нему индекс.

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

Вы посмотрите не на искосок, а вдумчиво. Тогда странные вопросы задавать не будете. И то, что кажется странным, станет очевидным.

hstory заменяется на jsonb, не стоит его использовать, запросто могут выкинуть.

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

хм, стою на асфальте я в лыжи обутый postgres-# \l test2 Список баз данных Имя | Владелец | Кодировка | LC_COLLATE | LC_CTYPE | Права доступа -------+------------+-----------+-------------+-------------+--------------- test2 | klimenko_a | UTF8 | ru_RU.UTF-8 | ru_RU.UTF-8 | (1 строка)вроде как никаких прав доступа к бд не выдано, по крайней мере не видно ни в консоли, ни в PgAdmin4. Но левым пользователем совершенно спокойно позволяет подключиться к бд делаем запрос REVOKE CONNECT ON DATABASE test2 FROM PUBLIC;неожиданно получаем postgres=# \l test2 Список баз данных Имя | Владелец | Кодировка | LC_COLLATE | LC_CTYPE | Права доступа -------+------------+-----------+-------------+-------------+--------------------------- test2 | klimenko_a | UTF8 | ru_RU.UTF-8 | ru_RU.UTF-8 | =T/klimenko_a + | | | | | klimenko_a=CTc/klimenko_a (1 строка) возможность подключиться у сторонних пользователей пропадает. О_о это нормально?

Но на jsonb посмотреть, я думаю, стоит.

Что вас заставило предположить такое непотребство?! о_О

Нормально. https://postgrespro.ru/docs/postgresql/9.6/sql-grant внимательно изучить пункт GRANT для объектов баз данных

извиняюсь) тогда разверните мысль про jsonb

А ещё на то, что права, предоставляемые по-умолчанию, не отображаются в выводе соответствующих команд

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

Вы так рассуждаете, будто у пользователей ПГ есть собственный выбор, кроме как запилить свой форк с шахматами и фрейлинами. Логика очень простая и понятная: есть роль public. Права этой роли наследуют все. Права, унаследованные от public не отображаются. Если при создании БД вы не отозвали у public привелегии - вы сами себе злобный буратино.

оконные функции в pg требуют вначале вытащить все данные и проагрегировать их, никакого piplene mode тут не получится((

Чем можно экспортнуть схему в json или yaml? есть какие-то проверенные cli тулзы?

https://github.com/perseas/Pyrseas

https://github.com/perseas/Pyrseas

тут в том числе и разработчики из PgPro присутствуют, ну и стало понятно что я всё правильно понимаю, и это действительно такое поведение БД (на мой взгляд не правильное) Я вот представляю как я буду админам рассказывать это, а вот тут вы создали бд, вот тут можно посмотреть права на данную бд, но тут на самом деле не все права, а есть ещё скрытые которые не видно, на меня как на идиота посмотрят. тут встанет закономерный вопрос сколько ещё такой магии, которая не логична и ради которой надо изучить вдоль и поперёк документацию (никто из них этого делать не будет). Продукт должен стремиться к уменьшению порога входа и уменьшению "магии". с темплейтов уже отозвал эти права.

тут в том числе и разработчики из PgPro присутствуют, ну и стало понятно что я всё правильно понимаю, и это действительно такое поведение БД (на мой взгляд не правильное) Я вот представляю как я буду админам рассказывать это, а вот тут вы создали бд, вот тут можно посмотреть права на данную бд, но тут на самом деле не все права, а есть ещё скрытые которые не видно, на меня как на идиота посмотрят. тут встанет закономерный вопрос сколько ещё такой магии, которая не логична и ради которой надо изучить вдоль и поперёк документацию (никто из них этого делать не будет). Продукт должен стремиться к уменьшению порога входа и уменьшению "магии". с темплейтов уже отозвал эти права.

По моему опыту админы такое не читают, а действуют железобетонными методами "мы вас по разным машинам развели и по vpn отдельно завайтистили"

Ну а вообще это речь об "общих" админах. По мне так нужен именно админ бд. Я вот почитал доку - понял кажись чего плстгис недоапнулась. Линки переписввать не пришлось. Просто в бд нужно было вызвать экстеншн апдейт. У меня на сервере, даже со 127.* вход строго по паролю. Вероятно не удалось базы в кластере апнуть без постгрис пользователя

почему ваши админы не захотят читать документацию?

Несоразмерность усилий и результата, это мне как разработчику интересен PG, в некоторых внутренних проектах я его сам и админю (как и ещё ряд разрабов). и составляет это всё очень небольшую часть от Mysql(этим какраз админы линуксоиды занимаются, как и самими серверами на линуксе) и MSsql(это уже отдельные личности). Работы у них и так непочатый край. Вдруг резко тратить кучу усилий на осваивание PG им даже просто никто не даст.

Кстати, вопрос. А есть сертифицированая специальность администратор pg? Вот в оракл кажется есть

Завели инстанс rds и в путь

не в жись не одобрят использование подобного внешнего сервиса, всё должно быть на наших серваках в нашей сети

Так они еще и железки чинят?

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

А архитектор у вас выделенный есть? :)

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

Эм, а почему так? Как будет выглядеть разъезжание, когда кто-то сожрет все ресурсы?

диск смонтирован на эту точку. Через postgresql.conf это как-то конфижится?

Кто знает как в firebird параметры запроса передать...