https://opennet.me/openforum/vsluhforumID3/112425.html После года разработки доступна (https://www.postgresql.org/about/news/1786/) новая стабильная ветка СУБД PostgreSQL 10. Обновления для новой ветки будут выходить (http://www.postgresql.org/support/versioning/) в течение пяти лет до октября 2022 года. Выбор номера версии 10 вместо 9.7.0 связано с переходом (http://www.databasesoup.com/2016/05/changing-postgresql-version-numbering.html) проекта на новую нумерацию выпусков. Вместо трёхуровневневой нумерации (Major1.Major2.Minor) отныне будет применяться схема "Major.Minor", в которой "Major" указывает номер значительной ветки, а "Minor" - номер корректирующего обновления, не требующего перезаливки БД. Таким образом, первым корректирующим релизом PostgreSQL 10 станет 10.1, а следующей значительной версией PostgreSQL 11. Как и раньше значительные версии будут формироваться раз в год.<br><br><br><br><br><br><br><br>Основные новшества (https://wiki.postgresql.org/wiki/New_in_postgres_10):<br><br><br><br><br><br>- Режим логической репликации (https://blog.2ndquadrant.com/logical-replication-pos https://opennet.me/openforum/vsluhforumID3/112425.html#121 Thu, 12 Oct 2017 13:42:35 GMT &gt;&gt; 3 ТБ/с даже для оперативки овердохрена, не говоря уж о том, что <br><br>Об этом и речь - головой нужно думать, если у тебя есть нормальный инструмент.<br><br><br>&gt; Шардинг же... таблица раскидана на 100 серверов...<br><br>index-only scan по одному измерению + partitioning по другому. Посмотрел на результаты - шардинг оказался даже не нужен.<br> https://opennet.me/openforum/vsluhforumID3/112425.html#120 Thu, 12 Oct 2017 06:52:59 GMT &gt;&gt; No, it's super-trans-hyper-pooper-webscale!<br>&gt; Pooper это профессия от слова poop?<br><br>Словарь не тут. ---Ж*** есть, а слова нету.<br> https://opennet.me/openforum/vsluhforumID3/112425.html#119 Thu, 12 Oct 2017 00:40:46 GMT &gt; No, it's super-trans-hyper-pooper-webscale!<br><br>Pooper это профессия от слова poop?<br> https://opennet.me/openforum/vsluhforumID3/112425.html#118 Wed, 11 Oct 2017 16:06:31 GMT &gt; Надежда умирает последней.<br><br>Хорошо, что ты не Надежда.<br> https://opennet.me/openforum/vsluhforumID3/112425.html#117 Tue, 10 Oct 2017 18:19:13 GMT На go? Люто проиграл с этого. Казалось, что на go переходят только php и python программисты. А теперь я узнал, что и джависты, которые не смогли осилить скалу.<br> https://opennet.me/openforum/vsluhforumID3/112425.html#116 Tue, 10 Oct 2017 04:26:03 GMT &gt;&gt; Неужели в 2017-м году ещё кто-то не в курсе, что это реляционная модель плохо ложится на реальность, а не ООП на реляционку.<br>&gt; Я тебе сейчас очень страшную вещь скажу Листок бумаги с буковками не имеет <br>&gt; методов, он не умеет сам ничего делать. <br><br>Ну и глупость пишешь. Ты из тех "спецов" по ООП у которых прям настоящее наследование на struct-ах делается.<br> https://opennet.me/openforum/vsluhforumID3/112425.html#115 Tue, 10 Oct 2017 04:21:50 GMT &gt;&gt; Сказки-с. В жабке Integer занимает 40-70 БАЙТ. Смотря какой режим, гггг <br>&gt; То есть ты пытаешься мне доказать, что ООП дает штраф не в <br>&gt; 10%, а все 1000%. Ну окей, верю, что в жабке это <br>&gt; так, но я говорил про ООП в нормальных языках.<br><br>Это не отменяет того факта, что жабка номер один везде, кроме опеннета. 8))<br><br>&gt;&gt; Про орм - оно может и выигрыш давать, от рук зависит.<br>&gt; Само собой, если кривизна рук погромиста не позволяет ему писать нормальные SQL <br>&gt; запросы, то ORM может иногда эту кривизну компенсировать.<br><br>Совершенно неправильно, ORM кривизну не компенсирует. Максимальный профит от ORM когда прогер знает SQL и ORM, но его избавляют от рутины.<br> https://opennet.me/openforum/vsluhforumID3/112425.html#114 Mon, 09 Oct 2017 12:19:37 GMT "Комитом" унитазы моют. А БД -- транзакции ФИКСИРУЮТ.<br> https://opennet.me/openforum/vsluhforumID3/112425.html#113 Mon, 09 Oct 2017 09:45:07 GMT &gt; Неужели в 2017-м году ещё кто-то не в курсе, что это реляционная модель плохо ложится на реальность, а не ООП на реляционку.<br><br>Я тебе сейчас очень страшную вещь скажу, только ты присядь. ООП тоже очень плохо ложится на реальность. Листок бумаги с буковками не имеет методов, он не умеет сам ничего делать. И скрепленные или подшитые такие листочки, образующие документ, тоже не умеют сами по себе ничего делать, даже добавить новые листочки. Аналогично с папкой, в которой лежат документы и шкафом, где хранятся эти папки. Все они не умеют делать ровным счетом ничего. Это данные, но без методов. Вот такая вот суровая реальность. А вот схема работы реляционных БД, в которой есть СУБД(библиотекарь, секретарь) и собственно БД(шкафы, полки, папки, каталоги для индексации) почему-то очень реальность напоминает. Может потому, что с нее писалась. <br>