https://www.facebook.com/groups/postgresql/?fref=ts

блииин. не навижу фейсбуки линкедины и прочие слаки. есть что-нибудь более православное типа почты ?

хрен проймёшь как там написать

100500 контролов

Где тут лайк поставить предыдущему оратору?

блииин. не навижу фейсбуки линкедины и прочие слаки. есть что-нибудь более православное типа почты ?

есть :)

список рассылки postgresql hackers.

квест продолжается....

https://www.postgresql.org/list/

реально, нет почты чтоли.. что может быть проще.

How to Subscribe or Unsubscribe

ну можно сразу тем ребятам которые этим занимаются?

я тебе показал два места, откуда можно начать :)

да уж. пожалуй на этих местах и закончу.

а так этот чат много кто из pgpro читает.

Ну так если есть конкретные разрабы кто занимается именно залочками — почему б не скоратить цепочку ?

postgresql-hackers.

Fix possible data corruption when pg_upgrade rewrites a relation visibility map into 9.6 format (Tom Lane)

ну и баг, как написано, проявляется на big-endian машинах

ну и баг, как написано, проявляется на big-endian машинах

не совсем так

как описано тут

https://wiki.postgresql.org/wiki/Visibility_Map_Problems

https://www.postgresql.org/message-id/flat/18695.1477325088%40sss.pgh.pa.us#18695.1477325088@sss.pgh.pa.us

^^^ откуда ноги растут

@vadvmkn, а почему ты ушел из пгпро?

http://pastebin.com/iVptbTVm

Интересно то же самое без форка

@vadvmkn, а почему ты ушел из пгпро?

Ушёл всё же? интересно куда ?

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

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

в текущей сессии да. Но в 9.6 вроде есть что-то связанное с многопоточностью.

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

Процесс на коннект

я про ядро

или он в этих же процессах выполняет запросы?

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

Один коннект - один бекенд-процесс, внутри процессов до 9.6 нет распараллеливания, в 9.6 агрегирование, джойны, сексканы и вот это всё вроде как параллелится, я лично не проверял, утверждать не буду.

Один коннект - один бекенд-процесс, внутри процессов до 9.6 нет распараллеливания, в 9.6 агрегирование, джойны, сексканы и вот это всё вроде как параллелится, я лично не проверял, утверждать не буду.

в 9.6 параллелится чтение, но не тредами, а спавном отдельных процессов, чтобы ничего не поломать :)

в 9.6 параллелится чтение, но не тредами, а спавном отдельных процессов, чтобы ничего не поломать :)

То есть 1 процесс - агрегатор и несколько процессов - для чтения?

да

Уточнил у коллег - таки только секскан распараллеливается, что, на самом деле, грустно и печально. @Komzpa, спасибо за поправку.

агрегации параллелятся (но по секскану)

а когда будет не по секскану не слышно ? =)

многим это бы облегчило жизнь

А кто нибудь юзал jsonb тип для замены EAV модели?

Немного поздно, но всё же, с внешними ключами и констрейнтами может быть всё как-то совсем плохо, и зависит от того как вы используете EAV

а когда будет не по секскану не слышно ? =)

https://wiki.postgresql.org/wiki/EnterpriseDB_database_server_roadmap

и еще вот здесь немного по BRIN индексам http://blog.2ndquadrant.com/postgresql-10-roadmap/

спасиб, про BRIN в курсе

не за что

привет. Что посоветуете по миграции версий?

привет. Что посоветуете по миграции версий?

https://github.com/yandex/pgmigrate https://flywaydb.org

https://github.com/yandex/pgmigrate https://flywaydb.org

последняя не работает ссылка

по миграции версий пг или схемы данных внутри пг?

Схемы.

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

- flyway + liquibase + phinx

Благодарю. Сегодня ознакомлюсь со всеми в списке

Немного поздно, но всё же, с внешними ключами и констрейнтами может быть всё как-то совсем плохо, и зависит от того как вы используете EAV

Не очень понял что имеется ввиду :) Наверное проще чтобы я показал свою схему на базе jsonb

Коллеги, добрый день! Хочу обратиться к вам за советом. Необходимо запустить несколько баз на одном сервере, причем каждую на своем диске и желательно, добиться максимальной изоляции и "самостоятельности" файлов данных (возможно, файлы могут быть подключены к другому кластеру, или копироваться по отдельности). Ищу максимально устойчивый и безопасный вариант. Рассматривал вариант с разными табличными пространствами, но смущает, что метаданные остаются в главном каталоге, а также в случае потери табличного пространства, весь кластер может оказаться недоступным. Другой вариант - несколько инстансов pg, но при этом теряется эффективность использования ресурсов сервера. Может, кто-нибудь что-то может посоветовать. Пока просто рассматриваю варианты, взвешиваю плюсы/минусы.

Коллеги, добрый день! Хочу обратиться к вам за советом. Необходимо запустить несколько баз на одном сервере, причем каждую на своем диске и желательно, добиться максимальной изоляции и "самостоятельности" файлов данных (возможно, файлы могут быть подключены к другому кластеру, или копироваться по отдельности). Ищу максимально устойчивый и безопасный вариант. Рассматривал вариант с разными табличными пространствами, но смущает, что метаданные остаются в главном каталоге, а также в случае потери табличного пространства, весь кластер может оказаться недоступным. Другой вариант - несколько инстансов pg, но при этом теряется эффективность использования ресурсов сервера. Может, кто-нибудь что-то может посоветовать. Пока просто рассматриваю варианты, взвешиваю плюсы/минусы.

нынче модно всё отдельное заворачивать в отдельные контейнеры для максимальной изоляции :)

Коллеги, добрый день! Хочу обратиться к вам за советом. Необходимо запустить несколько баз на одном сервере, причем каждую на своем диске и желательно, добиться максимальной изоляции и "самостоятельности" файлов данных (возможно, файлы могут быть подключены к другому кластеру, или копироваться по отдельности). Ищу максимально устойчивый и безопасный вариант. Рассматривал вариант с разными табличными пространствами, но смущает, что метаданные остаются в главном каталоге, а также в случае потери табличного пространства, весь кластер может оказаться недоступным. Другой вариант - несколько инстансов pg, но при этом теряется эффективность использования ресурсов сервера. Может, кто-нибудь что-то может посоветовать. Пока просто рассматриваю варианты, взвешиваю плюсы/минусы.

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

нынче модно всё отдельное заворачивать в отдельные контейнеры для максимальной изоляции :)

модно не значит хорошо ;)

нынче модно всё отдельное заворачивать в отдельные контейнеры для максимальной изоляции :)

Т.е. вместо просто нескольких инстансов получим несколько инстансов в контейнерах...

ЗЫ. Про распределение ресурсов в контейнерах я в курсе.

Т.е. вместо просто нескольких инстансов получим несколько инстансов в контейнерах...

зато изоляции[изоленты] больше :)

Коллеги, добрый день! Хочу обратиться к вам за советом. Необходимо запустить несколько баз на одном сервере, причем каждую на своем диске и желательно, добиться максимальной изоляции и "самостоятельности" файлов данных (возможно, файлы могут быть подключены к другому кластеру, или копироваться по отдельности). Ищу максимально устойчивый и безопасный вариант. Рассматривал вариант с разными табличными пространствами, но смущает, что метаданные остаются в главном каталоге, а также в случае потери табличного пространства, весь кластер может оказаться недоступным. Другой вариант - несколько инстансов pg, но при этом теряется эффективность использования ресурсов сервера. Может, кто-нибудь что-то может посоветовать. Пока просто рассматриваю варианты, взвешиваю плюсы/минусы.

Ровно два варианта: отдельные таблеспейсы и отдельные инстансы. Плюсы/минусы познаются посредством чтения документации и осознания таковой.

зато изоляции[изоленты] больше :)

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

нынче модно всё отдельное заворачивать в отдельные контейнеры для максимальной изоляции :)

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

Ровно два варианта: отдельные таблеспейсы и отдельные инстансы. Плюсы/минусы познаются посредством чтения документации и осознания таковой.

Коллеги, спасибо. Буду копать

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

В контейнерах главное - научиться грамотно распределять нагрузку между ними, а это - далеко не тривиальная задача.

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

мы же прямо здесь вроде обсуждали вопрос оверхеда

мы же прямо здесь вроде обсуждали вопрос оверхеда

Когда? Я чегой-то не припоминаю... :(

Может меня ещё тут не было.

может, в кликхаус-чате

Но, в общем, околонулевой там оверхед

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

а никто не в курсе, реально ли поставить на убунту 16.10 с сайта postgrespro версию для 1с?

мы же прямо здесь вроде обсуждали вопрос оверхеда

в монгодб чатике вроде

в монгодб чатике вроде

А можно ссылку?

я точно в монгодб не состою

я точно в монгодб не состою

Я пока что тоже

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

https://telegram.me/MongoDBRussian

вот уж никогда не думал что в пг чате буду ссыль на монгу кидать )

спасибо за ссылку :)

знаю людей которые из постгреса сделали монгу. Уже пожалели что обновились на 9.5 и разрешили использовать jsonb.

Люди пожалели или вы пожалели? О чем именно?

Вот тоже интересно

программисты вместо создания табличек и построения связей стали пихать все в одну мегатаблицу с мегазаписями. говорят «нам так проще».

программисты вместо создания табличек и построения связей стали пихать все в одну мегатаблицу с мегазаписями. говорят «нам так проще».

Вот да

это не программисты

> программисты вместо создания табличек и построения связей стали пихать все в одну мегатаблицу с мегазаписями. говорят «нам так проще». Не только поэтому. Когда получилось, что нужно делать онлайново запрос с 20 джойнами с огромным rps и чтобы он работал не больше 10мс, пришлось придумывать, как таблицы объединять. Поэтому не гоните)

в результате уложились в 10мс то?

да

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

ну и в базе не возможно разобраться что тамк чему....

Еще наверное документы разнотипные?

ну и в базе не возможно разобраться что тамк чему....

кому от этого плохо?

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