https://www.opennet.dev/openforum/vsluhforumID3/107893.html Представлен (http://www.postgresql.org/about/news/1668/) первый бета-выпуск СУБД PostgreSQL 9.6, ключевым новшеством в котором является поддержка распараллеливания операций последовательного сканирования записей (Sequential Scan (http://www.postgresql.org/message-id/E1ZwVzN-0000Xz-5e@gemulon.postgresql.org)), слияния запросов (join (http://www.postgresql.org/message-id/E1aLyct-000314-UZ@gemulon.postgresql.org)) и агрегирования данных (http://www.postgresql.org/message-id/E1ahzxY-0004qA-GJ@gemulon.postgresql.org). При распараллеливании операция разбивается на части и каждая часть разбирается отдельным обработчиком, после чего результаты работы каждого обработчика объединяются, что позволяет существенно увеличить скорость обработки запроса на системах с большим числом процессорных ядер. Выигрыш особенно заметен для ресурсоёмких запросов, таких как сопоставление по регулярным выражениям. <br><br><br>Другие улучшения (https://wiki.postgresql.org/wiki/NewIn96):<br><br><br>- [[http://www.postgresql.org/message-id/E1aniiT-0008 https://www.opennet.dev/openforum/vsluhforumID3/107893.html#56 Thu, 29 Sep 2016 18:59:42 GMT Ок. А что в этом патче может понравится, если вместо реализации платформы для версионных БД ребята попытались сделать из Postgres - блокировочник? Видимо мне никогда не понять почему массивы, иерархия и текст имеет всегда один тип - 'bytea'... Почему 1с (по-умолчанию, без возможности от их отказаться) создает мне индексы размером с таблицу и использует их чуть реже чем никогда?<br><br>Про возможность поставить более эффективный GIN/GiST-индекс вместо B-tree для многопользовательского отчета с огромным количеством зависимостей - умолчу... <br><br>Резюмирую - это охерительных размеров костыль, который к тому же не применим к актуальным релизам без внесения правок к патчам.<br> https://www.opennet.dev/openforum/vsluhforumID3/107893.html#55 Fri, 20 May 2016 15:15:23 GMT Не давайте эту ссылку - она стартоватая<br><br>Сейчас лучше вот:<br><br>https://pgconf.ru/media/2016/05/20/Ласкин Лев.pdf<br>https://pgconf.ru/2016/90069<br>https://github.com/VanessaDockers/pgsteroids<br> https://www.opennet.dev/openforum/vsluhforumID3/107893.html#54 Wed, 18 May 2016 04:41:21 GMT <br>&gt; Там два косяка - медленная работа при соединении живых таблиц с виртуальными <br>&gt; (срез последних надо пихать в отдельную таблицу и тд) и работа <br>&gt; с таблицами регистров бухгалтерии - очень часто приходится перегружать слона ибо <br>&gt; дедлоки валят массово. ИМХО реализация Cross Join в слоне кривовато сделана. <br><br>Там еще главнее косяки есть.<br>У меня, например, при закрытии месяца MS SQL накладывает порядка 20000 блокировок, а Postgres - порядка 70000000. Если учесть, что темп наложения блокировок - примерно 2000 в секунду на MS SQL и до 3000 в секунду на Postgres, получаем феерическую разницу.<br>Эти данные видны в консоли 1С.<br>Остальные вычисления при закрытии месяца (самая нагруженная процедура IMHO) примерно одинаковы по времени, но на фоне вышесказанного это мелочи.<br><br>Что же касается взаимных блокировок - это давно решено. Если, конечно, доморощенные таланты не пишут собственных отчетов/обработок, плодящих бесконтрольные взаимные захваты объектов. <br><br><br> https://www.opennet.dev/openforum/vsluhforumID3/107893.html#53 Sun, 15 May 2016 16:59:08 GMT &gt; Там два косяка - медленная работа при соединении живых таблиц с виртуальными <br>&gt; (срез последних надо пихать в отдельную таблицу и тд) и работа <br>&gt; с таблицами регистров бухгалтерии - очень часто приходится перегружать слона ибо <br>&gt; дедлоки валят массово. ИМХО реализация Cross Join в слоне кривовато сделана. <br><br>Почему-то в OpenERP/Odoo, изначально заточенной под Постгрес - этих проблем нет. <br><br><br> https://www.opennet.dev/openforum/vsluhforumID3/107893.html#52 Sun, 15 May 2016 16:55:41 GMT &gt;&gt; у кровавого энтерпрайза никогда нет денег делать как положено <br>&gt; Клыкастый, это шедевр!!! (С)Сергей Светлаков <br><br>Супер :)<br> https://www.opennet.dev/openforum/vsluhforumID3/107893.html#51 Sun, 15 May 2016 16:53:32 GMT Если долго-долго (десятилетие+) затачивать продукт под целевую базу - то ничего удивительного, что на ней будет выигрыш в скорости.<br><br>Oracle для типичной установки 1C, среднеторговой фирмочки - слишком дорого. Требуемый DBA отдельный - тем более.<br><br>Предлагать опенсорс - непонтово. Нет "синэргетики бизнеса", т.е. взаимного проталкивания продаж. Не на кого потом переводить стрелки, "это не мы, это XXX глючит"...<br><br>Что можно еще впарить, если Oracle дорого? Вывод очевиден и иднозначен. MS SQL. Не Линтер же :)<br> https://www.opennet.dev/openforum/vsluhforumID3/107893.html#49 Sat, 14 May 2016 10:58:36 GMT &gt;&gt; Почему-то портянки запросов из 1С в MS SQL отрабатываются обычно в 2 раза быстрее.<br>&gt; Есть подозрение - потому что изначально затачивались именно под планировщик ms-sql.<br>&gt;&gt; На наших задачах в 1С MS SQL отрабатывает в 3-4 раза быстрее, чем Постгре на том же оборудовании. При тестах явно видно, что MS SQL нагружает 2-3 процессора, Постгре - всегда только 1.<br>&gt; Есть подозрение, что если составлять запросы с учётом планировщика постгри - всё <br>&gt; будет несколько иначе. Есть очень сильное подозрение, что если бы разрабы <br>&gt; 1С ориентировались на постгрю изначально, никаких бы патчей не понадобилось.<br><br>причина описана здесь http://www.silverbulleters.org/ne-obizhayte-linux-oida-ili-osobennosti-patcha-1s-dlya-postgresql/<br>и патчи ничего вредного не несут, тем более что делаются в плотном сотрудничестве 1С и профессиональной команды PostgreSql<br><br>&gt; Но да, я в курсе - у кровавого энтерпрайза никогда нет денег <br>&gt; делать как положено и потому все сидят и ждут, когда наконец <br>&gt; дома будут строить так, чтобы влезали https://www.opennet.dev/openforum/vsluhforumID3/107893.html#47 Fri, 13 May 2016 21:43:06 GMT Да одна вещь по большому счету нужна, чтобы не весь кластер реплицировался, а только схема по выбору..<br> https://www.opennet.dev/openforum/vsluhforumID3/107893.html#44 Fri, 13 May 2016 18:00:00 GMT &gt; насколько я понял из заявлений квадратов (разработчиков BDR) они готовы, но сообщество <br>&gt; не чешется) Также слышал о том что BDR не поддерживает некоторые <br>&gt; базовые фичи постгреса, и возможно поэтому с BDR не спешат. Хрен <br><br>UDR уже "завбросили". И кому оно впилось? <br><br>Ты внимательно читал мануал того BDR? В части "у нас БЫСТРО* и многомастерно! &lt;small&gt;просто скажите вашим программерам переписать эти с-ные приложения&lt;/small&gt; *без блокировок, прогремссивно!"<br><br>&gt; бы еще с BDR, вот это бы хотябы -<br><br>Табе вот уже подавай каких-то "новых" блестящек.<br><br>Про ужасы блестяшек [или примерно]<br>http://bonesmoses.org/2016/05/06/pg-phriday-big-data-is-hard/<br>