Представлен (http://www.postgresql.org/about/news/1668/) первый бета-выпуск СУБД PostgreSQL 9.6, ключевым новшеством в котором является поддержка распараллеливания операций последовательного сканирования записей (Sequential Scan (http://www.postgresql.org/message-id/E1ZwVzN-0000Xz-5e@...)), слияния запросов (join (http://www.postgresql.org/message-id/E1aLyct-000314-UZ@...)) и агрегирования данных (http://www.postgresql.org/message-id/E1ahzxY-0004qA-GJ@...). При распараллеливании операция разбивается на части и каждая часть разбирается отдельным обработчиком, после чего результаты работы каждого обработчика объединяются, что позволяет существенно увеличить скорость обработки запроса на системах с большим числом процессорных ядер. Выигрыш особенно заметен для ресурсоёмких запросов, таких как сопоставление по регулярным выражениям.
Другие улучшения (https://wiki.postgresql.org/wiki/NewIn96):
- [[http://www.postgresql.org/message-id/E1aniiT-00083J-4W@... Возможность] создания кластерных конфигураций, включающих несколько запасных узлов, реплицируемых в синхронном режиме.- Новый режим синхронной репликации "synchronous_commit = remote_apply (http://www.postgresql.org/message-id/E1al4z1-0004qD-GW@...)", при котором основной узел перед закрытием транзакции ожидает подтверждения приёма данных standby-узлом;
- В модуль postgres_fdw (http://www.postgresql.org/docs/9.6/static/postgres-fdw.html), позволяющий логически объединить содержимое БД с нескольких серверов, добавлена поддержка операций слияния (join) и сортировки запросов, а также выполнения операций UPDATE и DELETE на внешнем сервере;
- Новый API (http://www.postgresql.org/message-id/E1anVSA-0002zm-Gc@...) для создания горячих бэкапов, в котором метка резервной копии не записывается в директорию с данными, а возвращается как результат выполнения функции pg_stop_backup(), что позволяет защититься от проблем в случае краха во время бэкапа;
- Снижено негативное влияние операции "autovacuum" на работу больших таблиц, благодаря исключению (http://www.postgresql.org/message-id/E1ae7wj-0001mM-Ib@...) операций повторной заморозки ("refreezing") старых данных;- Реализована (http://www.postgresql.org/message-id/E1adhjH-0008RE-TV@...) подсистема для отображения прогресса выполнения операций, например, организовано (http://www.postgresql.org/message-id/E1afsqY-0003qB-Mb@...) информирование о времени до завершения VACUUM;- В систему полнотекстового поиска добавлен (http://www.postgresql.org/message-id/E1aoCJy-0004bp-HI@...) новый оператор ‹-› или ‹DISTANCE›, определяющий расстояние между словами;
- Добавлен (http://www.postgresql.org/message-id/E1adHwi-0007KB-TM@...) модуль pg_visibility.
URL: http://www.postgresql.org/about/news/1668/
Новость: http://www.opennet.dev/opennews/art.shtml?num=44414
Это очень круто. Один из тех продуктов, который стабильно из года в год вызывает уважение.
Вот ещё ссылка на клуб любителей PostgreSQLhttp://www.meetup.com/postgresqlrussia/about/comments/?op=all
Там даже есть наш Мишаня
http://www.meetup.com/postgresqlrussia/members/183070635/
Вообщем клуб солидный, без подвохов.
Мишаня подойдёт, может поделиться с нами инфой поэтому клубу.
Раньше они вначале альфы выпускали, а потом бету. А сейчас сразу бета-версия вышла и на пару месяцев раньше. Какие-то изменения в подготовке релизов?
и релиз из беты за полгода выкатывают, стрёмно чото
Будет интересно посмотреть, как 1С на нем крутится будет...
Никак. Не умеет 1с с полноценной, некастрированной постгрей работать. А умеет работать со спецсборками, и сборки эти очень даже не 9.6 версии.
> Никак. Не умеет 1с с полноценной, некастрированной постгрей работать. А умеет работать
> со спецсборками, и сборки эти очень даже не 9.6 версии.ну ка раскрой суть кастрации постгреса одинесовыми патчами? И да, там 9.4 уже, при том, что в шестой шапке 8.4, а в седьмой 9.2
>> Никак. Не умеет 1с с полноценной, некастрированной постгрей работать. А умеет работать
>> со спецсборками, и сборки эти очень даже не 9.6 версии.
> ну ка раскрой суть кастрации постгреса одинесовыми патчами? И да, там 9.4
> уже, при том, что в шестой шапке 8.4, а в седьмой
> 9.2"там" http://1c.postgrespro.ru/rpm/ уже и 9.5
я на users.v8.1c.ru смотрел, а 9.5 ещё рано, на мой взгляд, в продакшин тянуть
Школьнику на заметкуhttp://www.silverbulleters.org/ne-obizhayte-linux-oida-ili-o.../
Ок. А что в этом патче может понравится, если вместо реализации платформы для версионных БД ребята попытались сделать из Postgres - блокировочник? Видимо мне никогда не понять почему массивы, иерархия и текст имеет всегда один тип - 'bytea'... Почему 1с (по-умолчанию, без возможности от их отказаться) создает мне индексы размером с таблицу и использует их чуть реже чем никогда?Про возможность поставить более эффективный GIN/GiST-индекс вместо B-tree для многопользовательского отчета с огромным количеством зависимостей - умолчу...
Резюмирую - это охерительных размеров костыль, который к тому же не применим к актуальным релизам без внесения правок к патчам.
А вот как патчи сделают да к 1С прикрутят - тогда и посмотрим.
9.4 запрос на одном процессоре выполняет, оттого получается долго и печально. MS SQL куда шустрее работает.
Интересно будет 9.6 сравнить с MS SQL.
> А вот как патчи сделают да к 1С прикрутят - тогда и
> посмотрим.
> 9.4 запрос на одном процессоре выполняет, оттого получается долго и печально. MS
> SQL куда шустрее работает.куда шустрее? нука побалуйте бенчмарками
> Интересно будет 9.6 сравнить с MS SQL.
не интересно
>> А вот как патчи сделают да к 1С прикрутят - тогда и
>> посмотрим.
>> 9.4 запрос на одном процессоре выполняет, оттого получается долго и печально. MS
>> SQL куда шустрее работает.
> куда шустрее? нука побалуйте бенчмарками
>> Интересно будет 9.6 сравнить с MS SQL.
> не интересноу него в торгашиной методичке написано, что надо старательно игнорировать настройки постгреса, а то мсскуль соснёт нечаянно
оказывается проблема не в невменяемых портянках запросов, а в том, что они на одном ядре пашут.
Почему-то портянки запросов из 1С в MS SQL отрабатываются обычно в 2 раза быстрее.
Некоторые - в 5-10 раз быстрее (данные из логов 1С, Постгре и MS SQL).На наших задачах в 1С MS SQL отрабатывает в 3-4 раза быстрее, чем Постгре на том же оборудовании. При тестах явно видно, что MS SQL нагружает 2-3 процессора, Постгре - всегда только 1.
Поэтому и интересно будет посмотреть на Постгре с распараллеливанием обработки...
> Почему-то портянки запросов из 1С в MS SQL отрабатываются обычно в 2 раза быстрее.Есть подозрение - потому что изначально затачивались именно под планировщик ms-sql.
> На наших задачах в 1С MS SQL отрабатывает в 3-4 раза быстрее, чем Постгре на том же оборудовании. При тестах явно видно, что MS SQL нагружает 2-3 процессора, Постгре - всегда только 1.
Есть подозрение, что если составлять запросы с учётом планировщика постгри - всё будет несколько иначе. Есть очень сильное подозрение, что если бы разрабы 1С ориентировались на постгрю изначально, никаких бы патчей не понадобилось.
Но да, я в курсе - у кровавого энтерпрайза никогда нет денег делать как положено и потому все сидят и ждут, когда наконец дома будут строить так, чтобы влезали их окошки.> Поэтому и интересно будет посмотреть на Постгре с распараллеливанием обработки...
Будет лучше, но это слабое утешение.
>>Есть подозрение, что если составлять запросы с учётом планировщика постгри - всё будет несколько иначе.Там патчи в основном на сравнение данных без учета регистра.
>>Есть подозрение, что если составлять запросы с учётом планировщика постгри - всё будет несколько иначе.
Там два косяка - медленная работа при соединении живых таблиц с виртуальными (срез последних надо пихать в отдельную таблицу и тд) и работа с таблицами регистров бухгалтерии - очень часто приходится перегружать слона ибо дедлоки валят массово. ИМХО реализация Cross Join в слоне кривовато сделана.
> Там два косяка - медленная работа при соединении живых таблиц с виртуальными
> (срез последних надо пихать в отдельную таблицу и тд) и работа
> с таблицами регистров бухгалтерии - очень часто приходится перегружать слона ибо
> дедлоки валят массово. ИМХО реализация Cross Join в слоне кривовато сделана.Почему-то в OpenERP/Odoo, изначально заточенной под Постгрес - этих проблем нет.
> Там два косяка - медленная работа при соединении живых таблиц с виртуальными
> (срез последних надо пихать в отдельную таблицу и тд) и работа
> с таблицами регистров бухгалтерии - очень часто приходится перегружать слона ибо
> дедлоки валят массово. ИМХО реализация Cross Join в слоне кривовато сделана.Там еще главнее косяки есть.
У меня, например, при закрытии месяца MS SQL накладывает порядка 20000 блокировок, а Postgres - порядка 70000000. Если учесть, что темп наложения блокировок - примерно 2000 в секунду на MS SQL и до 3000 в секунду на Postgres, получаем феерическую разницу.
Эти данные видны в консоли 1С.
Остальные вычисления при закрытии месяца (самая нагруженная процедура IMHO) примерно одинаковы по времени, но на фоне вышесказанного это мелочи.Что же касается взаимных блокировок - это давно решено. Если, конечно, доморощенные таланты не пишут собственных отчетов/обработок, плодящих бесконтрольные взаимные захваты объектов.
> у кровавого энтерпрайза никогда нет денег делать как положеноКлыкастый, это шедевр!!! (С)Сергей Светлаков
>> у кровавого энтерпрайза никогда нет денег делать как положено
> Клыкастый, это шедевр!!! (С)Сергей СветлаковСупер :)
>> Почему-то портянки запросов из 1С в MS SQL отрабатываются обычно в 2 раза быстрее.
> Есть подозрение - потому что изначально затачивались именно под планировщик ms-sql.
>> На наших задачах в 1С MS SQL отрабатывает в 3-4 раза быстрее, чем Постгре на том же оборудовании. При тестах явно видно, что MS SQL нагружает 2-3 процессора, Постгре - всегда только 1.
> Есть подозрение, что если составлять запросы с учётом планировщика постгри - всё
> будет несколько иначе. Есть очень сильное подозрение, что если бы разрабы
> 1С ориентировались на постгрю изначально, никаких бы патчей не понадобилось.причина описана здесь http://www.silverbulleters.org/ne-obizhayte-linux-oida-ili-o.../
и патчи ничего вредного не несут, тем более что делаются в плотном сотрудничестве 1С и профессиональной команды PostgreSql> Но да, я в курсе - у кровавого энтерпрайза никогда нет денег
> делать как положено и потому все сидят и ждут, когда наконец
> дома будут строить так, чтобы влезали их окошки.
>> Поэтому и интересно будет посмотреть на Постгре с распараллеливанием обработки...
> Будет лучше, но это слабое утешение.а бенчи есть здесь http://efsol.ru/articles/performance-1s-postgre-ms-sql.html
там нет никаких 3-4 раза, есть полтора, но кривость рук разработчиков может может сотворить чудо ;)
и это "без распараллеливания" как тут выразились
Если долго-долго (десятилетие+) затачивать продукт под целевую базу - то ничего удивительного, что на ней будет выигрыш в скорости.Oracle для типичной установки 1C, среднеторговой фирмочки - слишком дорого. Требуемый DBA отдельный - тем более.
Предлагать опенсорс - непонтово. Нет "синэргетики бизнеса", т.е. взаимного проталкивания продаж. Не на кого потом переводить стрелки, "это не мы, это XXX глючит"...
Что можно еще впарить, если Oracle дорого? Вывод очевиден и иднозначен. MS SQL. Не Линтер же :)
Не давайте эту ссылку - она стартоватаяСейчас лучше вот:
https://pgconf.ru/media/2016/05/20/Ласкин Лев.pdf
https://pgconf.ru/2016/90069
https://github.com/VanessaDockers/pgsteroids
без доработки напильником - никак не будет
А аналог MS-SQL BACKUP LOG имеется в слонике? Или там надо как и раньше плясать с бубнами и настраивать резервного слона, что бы можно было восстановить архив на произвольный момент времени?
>А аналог MS-SQL BACKUP LOG имеется в слонике? Или там надо как и раньше плясать с бубнами и настраивать резервного слона, что бы можно было восстановить архив на произвольный момент времени?Есть, правда реализация больше похожа на Oracle, нежели на M$ SQL.
Детали в официальной документации: http://www.postgresql.org/docs/9.5/static/continuous-archivi...
Ай-яй-яй, ну как так можно, *самое* замечательное, что ждем в этом релизе, и не упомянуть! Теперь GIN-индексы можно создавать с любым maintenance_work_mem. Сейчас постоянно для пересоздания каких-то индексов приходится его до гига урезать, а для одного уже до 500 мегабайт, иначе создание падает с нехваткой памяти (а так как GIN загаживаются быстро, пересоздавать приходится регулярно). Из-за чего pg_repack автоматом не запустить и прочие радости...
Распараллеливание, ИМХО, более фундаментальное и ожидаемое улучшение
подскажите пожалуйста я правильно понимаю что в синхронном режиме пришедший update сначала идет на slave сервер, записывается, делается fsync (если разрешен), далее master записывает себе, делает fsync (если разрешен) и только затем говорит клиенту что update прошел?те при падении master мы можем сразу переключиться на slave потому что он гарантированно синхронен?
а как сюда вяжется "synchronous_commit = remote_apply"?
объясните пожалуйста если знаете как это работает, заранее большое спасибо!
Пришедший апдейт сначала пишется в журнал WAL и оттуда отправляется на слейв, на слейве он применяется, об этом уведомляется мастер, и только тогда мастер завершает исполнение запроса, пока уведомление не придет мастер тупо ждет. Да, при падении мастера можно сразу переключится на слейв, он синхронен. Это и есть remote_apply. Как происходит обработка если от слейва ответ не пришел не знаю, могу предположить что запись в журнале "остается непримененной"
а в чем тогда разница между режимами remote_apply и on?
Если on то мастер считает что изменение прошло не когда оно было применено слейвом, а когда оно было только принято им
выходит remote_apply наиболее синхронный и безопасный к падению и переключению режим. спасибо!
подскажите когда в postgres появиться master-master? знаю про BDR, когда это будет в официальном postgres?
> подскажите когда в postgres появиться master-master? знаю про BDR, когда это будет
> в официальном postgres?Никогда потому, что это не SQL.
>Никогда потому, что это не SQL.Что за бред? я тестировал летом связку из трех серверов в BDR - создавал таблицы, делал в них insert, добавлял поля, менял типы полей - все менялось на всех трех серверах с какого бы я это не делал. в продакшене не использовали, просто поигрались и убедились что изменения синхронизируются без всяких триггеров.
>>Никогда потому, что это не SQL.
> Что за бред? я тестировал летом связку из трех серверов в BDR
> - создавал таблицы, делал в них insert, добавлял поля, менял типы
> полей - все менялось на всех трех серверах с какого бы
> я это не делал. в продакшене не использовали, просто поигрались и
> убедились что изменения синхронизируются без всяких триггеров.Попробуй поменять на 100 гиговой базе с внешними ключами. Просто интересно сколько это займет.
насколько я понял из заявлений квадратов (разработчиков BDR) они готовы, но сообщество не чешется) Также слышал о том что BDR не поддерживает некоторые базовые фичи постгреса, и возможно поэтому с BDR не спешат. Хрен бы еще с BDR, вот это бы хотябы - http://www.postgresql.org/about/news/1666/ ))
> насколько я понял из заявлений квадратов (разработчиков BDR) они готовы, но сообщество
> не чешется) Также слышал о том что BDR не поддерживает некоторые
> базовые фичи постгреса, и возможно поэтому с BDR не спешат. ХренUDR уже "завбросили". И кому оно впилось?
Ты внимательно читал мануал того BDR? В части "у нас БЫСТРО* и многомастерно! <small>просто скажите вашим программерам переписать эти с-ные приложения</small> *без блокировок, прогремссивно!"
> бы еще с BDR, вот это бы хотябы -
Табе вот уже подавай каких-то "новых" блестящек.
Про ужасы блестяшек [или примерно]
http://bonesmoses.org/2016/05/06/pg-phriday-big-data-is-hard/
Да одна вещь по большому счету нужна, чтобы не весь кластер реплицировался, а только схема по выбору..