https://opennet.dev/openforum/vsluhforumID3/102382.html В дерево исходных текстов СУБД PostgreSQL приняты изменения (http://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=924bcf4f16d54c55310b28f77686608684734f42) с реализацией инфраструктуры для параллельных вычислений, предоставляющей следующие возможности:<br><br><br><br>- Удобные процедуры для координирования запуска и завершения работы параллельно выполняемых рабочих процессов;<br>- Синхронизация различных внутренних состояний (GUCs, комбинированный маппинг CID, снапшоты транзакций) между лидером группы параллельных работ и непосредственно распараллелеными рабочими процессами;<br>- Ограничение вызова различных операций, которые могут привести к внесению некорректных изменений в условиях активного распараллеливания;<br>- Доставка уведомлений клиенту через сообщения ErrorResponse,<br>NoticeResponse и NotifyResponse от работающих в параллельном режиме обработчиков.<br><br><br><br><br>Дополнительно, можно отметить появление (http://www.opennet.ru/soft/job_PostgreSQL.odt) в компании Postgres Professional, в которой работают мно https://opennet.dev/openforum/vsluhforumID3/102382.html#48 Wed, 13 May 2015 15:53:05 GMT &gt; Та же история с ssh. Держать на стандартном 22 порту или перевесить? :)<br><br>как же смИшно выглядят скриптикиддис перевешивающие с 22 на другой порт.<br>по-вашему перебор портов для бота более занудная процедура, чем перебор пароля?<br><br>добавьте уже один раз в /etc/ssh/sshd_config строку:<br>AuthenticationMethods publickey<br><br>и будет вам счастье<br> https://opennet.dev/openforum/vsluhforumID3/102382.html#47 Fri, 08 May 2015 09:46:14 GMT уже<br><br>https://github.com/postgres/postgres/commit/168d5805e4c08bed7b95d351bf097cff7c07dd65<br> https://opennet.dev/openforum/vsluhforumID3/102382.html#46 Wed, 06 May 2015 13:38:51 GMT Два момента где многопоточность будет рулить:<br>1. неблокирующее чтение, в том числе с нескольких физических устройств сразу (для распределенных таблиц), возможно будет и упреждающее чтение<br>2. распараллеливание тяжелых запросов где грузится процессор (сортировка, GiST)<br> https://opennet.dev/openforum/vsluhforumID3/102382.html#45 Wed, 06 May 2015 12:26:43 GMT Строчкой ниже и с теми же полями. Правда, красота? &lt;/sarcasm&gt;<br>Но реально редко напрягает, т.к. прячется за более высокоуровневым синтаксисом.<br> https://opennet.dev/openforum/vsluhforumID3/102382.html#44 Tue, 05 May 2015 19:14:42 GMT Основной недостаток redis-а - персистенция через fork(): при большом потоке записей copy-on-write может раздуть процессы до срабатывания oom killer. overcommit_memory проблему решает, но костыль еще тот.<br> https://opennet.dev/openforum/vsluhforumID3/102382.html#43 Tue, 05 May 2015 14:56:07 GMT &gt;вот человек мерял http://michael.otacoo.com/postgresql-2/unlogged-table-performance-in-postgres и говорит о росте не более 20% на его задаче. <br><br>Так это общее ускорение ответа страниц, отработка запросов к таблицам постгреса ускоряется в разы, особенно при частых вставках.<br> https://opennet.dev/openforum/vsluhforumID3/102382.html#42 Tue, 05 May 2015 14:42:00 GMT отож.<br><br>&gt; 45% of acknowledged writes were thrown away. To add insult to injury, Redis preserved all the failed writes in place of the successful ones<br><br>https://aphyr.com/posts/307-call-me-maybe-redis-redux<br> https://opennet.dev/openforum/vsluhforumID3/102382.html#41 Tue, 05 May 2015 13:23:58 GMT Как вариант многопоточные хранимки, если например внутри хранимки надо сделать несколько тяжелых запросов, то их можно запустить параллельно<br> https://opennet.dev/openforum/vsluhforumID3/102382.html#40 Tue, 05 May 2015 07:29:08 GMT Зачем это? Реализовывать процедуры, которые будут в фоне на стороне базы работать?<br>