https://www.opennet.me/openforum/vsluhforumID3/117323.html Сформированы (https://www.postgresql.org/about/news/1939/) корректирующие обновления для всех поддерживаемых веток PostgreSQL: 11.3 (https://www.postgresql.org/docs/current/static/release-11-3.html), 10.8 (https://www.postgresql.org/docs/current/static/release-10-8.html), 9.6.13 (http://www.postgresql.org/docs/current/static/release-9-6-13.html), 9.5.17 (http://www.postgresql.org/docs/current/static/release-9-5-17.html) и 9.4.22 (http://www.postgresql.org/docs/current/static/release-9-4-22.html), в которых представлена порция исправлений ошибок. Выпуск обновлений для ветки 9.4 продлится (http://www.postgresql.org/support/versioning/) до декабря 2019 г., 9.5 до января 2021 г., 9.6 - до сентября 2021 года, 10 - до октября 2022 года, 11 - до ноября 2023 года. <br><br><br><br>В новых версиях исправлено более 60 ошибок и устранено четыре уязвимости:<br><br><br>- Две уязвимости (CVE-2019-10127, CVE-2019-10128) специфичны для уплатформы Windows и проявляются в инсталляторах от компаний EnterpriseDB и BigSQL, которые не выставл https://www.opennet.me/openforum/vsluhforumID3/117323.html#58 Sat, 18 May 2019 06:36:09 GMT &gt; Есть "оптимистичное" предположение,<br><br>Да. Оптимистично только журнал. Но это при условии что нагрузка нерегулярная и иногда дает покурить. А если постоянная и на максимуме, как в свое время в Сбере, то в какой-то момент времени выясняется, что терабайт памяти пишется на диск не моментально, а если запаниковать, то его еще из журналов восстанавливать надо, что тоже не ускоряет процесс.<br> https://www.opennet.me/openforum/vsluhforumID3/117323.html#57 Wed, 15 May 2019 03:19:06 GMT &gt; ... и надежности, как у mysql<br><br>Это в смысле когда база мыскля вдруг тупо впадает в задумчивость и оживает только после прохода <br>mysqlcheck -r -f ?<br> https://www.opennet.me/openforum/vsluhforumID3/117323.html#56 Tue, 14 May 2019 19:03:12 GMT Ради параллельных вычислений на 11 стоит<br> https://www.opennet.me/openforum/vsluhforumID3/117323.html#55 Tue, 14 May 2019 19:02:36 GMT Тоже 11 в проде<br> https://www.opennet.me/openforum/vsluhforumID3/117323.html#54 Tue, 14 May 2019 10:35:09 GMT если тебе понадобился тонкий тюнинг innodb - посгрез на этом же железе на той же задаче уже давно бы лопнул или необратимо бы крэшнул базу.<br><br>Во всяком случае, если решать ее в лоб, игнорируя оптимизатор-планировщик и особенности хранения. Чего, понятное дело, ни один разработчик не любит, поскольку вся эта оптимизация для того и придумана, чтобы не заморачиваться особенностями конкретной субд.<br> https://www.opennet.me/openforum/vsluhforumID3/117323.html#53 Tue, 14 May 2019 10:32:33 GMT бросьте, вот только что приходил товарисч, взгромоздивший на постгрез zabbix. В конторе до 1000 и никто его не заставлял.<br>(ну да, ну да - с его бесконечными поштучными insert, запросами where ... in ( ) , и "housekeeping" с delete where in - что ведет к интересным последствиям для постргезовой уродливой системы хранения, с ее "vacuum ненужен, ненужен, ненужнен!" )<br><br>А фэйловерили они ее побайтовым копированием, ага.<br><br>Не завидую пришедшему ему на смену.<br><br><br><br> https://www.opennet.me/openforum/vsluhforumID3/117323.html#52 Tue, 14 May 2019 10:27:46 GMT &gt; В PostgreSQL при помощи обилия ручек вы можете<br><br>кое-как добиться почти такой же производительности и надежности, как у mysql из коробки - если повезет с workload.<br>Поправил, не благодари.<br><br> https://www.opennet.me/openforum/vsluhforumID3/117323.html#51 Tue, 14 May 2019 10:26:03 GMT ну так он вызван изначальной глупостью - пытаться вместо чистого форка сделать drop-in replacement. В результате совместимость все равно поломана, но вот удержать на одном хосте две разные - теперь неприемлемый геморрой (слава виртуалочкам, что уже низачем и не нужно)<br><br> https://www.opennet.me/openforum/vsluhforumID3/117323.html#50 Mon, 13 May 2019 08:08:59 GMT &gt;&gt;Oracle, грубо говоря, удваивает объем выполняемой записи в журнал <br>&gt; Ну если грубо говоря, то учетверяет. Пишем журнал-&gt;undo-&gt;журнал-&gt;обновленную запись. <br><br>Удваивает *запись в журнал* - т.е. синхронную запись, которая напрямую влияет на скорость выполнения.<br>Вся остальная запись асинхронная, и влияние её косвенное (увеличивает количество IOPS, но при этом хорошо параллелится и не блокирует дальнейшие действия приложения).<br> <br>&gt; В PG 3 : журнал-&gt;новая-&gt;пометка старой <br>&gt; У Oracle выигрыш в использовании места (а соответственно быстрее full scan) <br>&gt; на частых update, но и chained rows как следствие.<br><br>Алгоритмы Oracle сокращают фрагментацию основного табличного пространства ценой двойной фиксации изменений: в основное табличное пространство и в UNDO.<br>