В дерево исходных текстов СУБД PostgreSQL приняты изменения (http://git.postgresql.org/gitweb/?p=postgresql.git;a=commitd...) с реализацией инфраструктуры для параллельных вычислений, предоставляющей следующие возможности:- Удобные процедуры для координирования запуска и завершения работы параллельно выполняемых рабочих процессов;
- Синхронизация различных внутренних состояний (GUCs, комбинированный маппинг CID, снапшоты транзакций) между лидером группы параллельных работ и непосредственно распараллелеными рабочими процессами;
- Ограничение вызова различных операций, которые могут привести к внесению некорректных изменений в условиях активного распараллеливания;
- Доставка уведомлений клиенту через сообщения ErrorResponse,
NoticeResponse и NotifyResponse от работающих в параллельном режиме обработчиков.
Дополнительно, можно отметить появление (https://www.opennet.ru/soft/job_PostgreSQL.odt) в компании Postgres Professional, в которой работают многие известные отечественные разработчики PostgreSQL, вакансий разработчиков на языке C для работы над ядром СУБД PostgreSQL. Трудоустройство на полный рабочий день в Москве. Работа подразумевает создание новой функциональности ядра СУБД PostgreSQL, участие в Open Source проектах и обеспечение поддержки 3-го уровня (исправление ошибок, поиск и решение проблем). Контакты для связи: obartunov@postgrespro.ru и a.korotkov@postgrespro.ru.
URL: http://www.postgresql.org/message-id/E1Ynu2T-0005iK-Gf@...
Новость: https://www.opennet.ru/opennews/art.shtml?num=42158
Публикация e-mail в удобном для спам ботов виде крайне способствует засорению персонального почтового ящика.
>Публикация e-mail в удобном для ... видеЭто называется вежливость.
Разгадывать ребусы вроде:
o(a+)(искусство по-английски)unov(коммерческая собака)postgrespro(тчк)ru
не в кайф. Особенно если действительно надо выйти на связь.
ИМХО, но это точно не вежливость. Вежливость - это когда для резюме кандидатов открывают отдельный e-mail и, при необходимости, краткий help. А забитый спамом персональный e-mail ведущих разработчиков это, простите, "свинью положили".
Работал в провайдере, на сайте был открытым текстом адрес support@..., редиректился на мой персональный email, на мой же адрес редиректились hd@, helpdesk@, help@, abuse@, webmaster@, postmaster@ и ещё какие-то, все уже не помню. В день - два-три-пять собщений, пик - около десятка, в основном на русском. После обучения SA переставали проходить и они.
Вообще-то rfc5321 как раз требует, чтобы postmaster@ не фильтровался.Да и abuse@, ИМХО лучше не фильтровать.
Я ребусы (полегче) встречал только на русских сайтах. А так я вижу только типа mail(at)example(dot)com
>mail(at)example(dot)comНеужели ты думаешь, что для сборщиков адресов этот адрес хоть как-то отличается от написанного прямым текстом? На улице 21 век, гигагерцовые процессоры и прочие достижения...
От профессионала спасёт только ещё более крутой профессионал. От скриптидис - спасёт.
Та же история с ssh. Держать на стандартном 22 порту или перевесить? :)
Как говаривал старик Шекспирыч: ту бир ор нот ту бир?!
> Та же история с ssh. Держать на стандартном 22 порту или перевесить? :)как же смИшно выглядят скриптикиддис перевешивающие с 22 на другой порт.
по-вашему перебор портов для бота более занудная процедура, чем перебор пароля?добавьте уже один раз в /etc/ssh/sshd_config строку:
AuthenticationMethods publickeyи будет вам счастье
> Это называется вежливость.
> Разгадывать ребусы вроде:
> o(a+)(искусство по-английски)unov(коммерческая собака)postgrespro(тчк)ru
> не в кайф. Особенно если действительно надо выйти на связь.Либо вообще можно было бы так сделать: <span class="email">mail ...AAAATTTT... example ...DOOOT... com</span>, а затем с помощью JS сделать нормальный e-mail.
Спам-боты уже сто лет как умеют выполнять JS-скрипты.
> Это называется вежливость.
> Разгадывать ребусы вроде:
> o(a+)(искусство по-английски)unov(коммерческая собака)postgrespro(тчк)ru
> не в кайф. Особенно если действительно надо выйти на связь.
>Либо вообще можно было бы так сделать: <span class="email">mail ...AAAATTTT... example ...DOOOT... com</span>, а затем с помощью JS сделать нормальный e-mail.А можно просто создать отдельный e-mail аналогичный resume@postgrespro.ru и пояснить, что для быстрой связи с Бортуновым О. письмо должно начинаться фразой : "Вниманию Олега Бортунова". Procmail или иной фильтр облегчит жизнь и оператору и Олегу.
И, возможно, стоит перейти к содержанию новости, форма подачи, похоже получила свою долю внимания.
Можно привести сравнительный пример выгод использования параллельно выполняемых рабочих процессов.
это называется фсб
> Публикация e-mail в удобном для спам ботов виде крайне способствует засорению персонального
> почтового ящика.А с приходом Яндекса/GMail'а такая проблема как спам еще существует?
скажите когда же в postgres уже появиться merge/upsert ???
во-во, +100
http://www.depesz.com/2012/06/10/why-is-upsert-so-complicated/
это все извращения, локи, ловля исключений. нужно просто сделать нормальный штатный механизм
Займись на досуге.
> http://www.depesz.com/2012/06/10/why-is-upsert-so-complicated/Особое удовольствие когда на таблице несколько ограничений уникальности или пр. причин для исключения)
insert into mytable (col1,col2) (select distinct * from (values ('val1','val2')) as tmp (col1,col2) where not exists (select 1 from mytable t where t.col1 = tmp.col1 and t.col2 = tmp.col2))
а апдейт где?
Строчкой ниже и с теми же полями. Правда, красота? </sarcasm>
Но реально редко напрягает, т.к. прячется за более высокоуровневым синтаксисом.
ужеhttps://github.com/postgres/postgres/commit/168d5805e4c08bed...
Вот интересно, когда появится возможность создавать таблицы в памяти, аналог memory таблиц у MySQL?
это считай есть, man tablespace
Читал. Это не то.
Это то - создай tablespace в tmpfs
В версии 9.1 появились unlogged tables
а они разве какое-то отношение к engine=memory имеют? мне всю дорогу казалось, что нет
Имеют, они в разы быстрее обычных, но не журналируются (и не реплицируются). За меньшую скорость относительно таблиц mysql "только в памяти" снимается ограничение на размер. А также переживает не аварийный перезапуск сервера.Можно почитать здесь: http://www.depesz.com/2011/01/03/waiting-for-9-1-unlogged-ta.../
> Имеют, они в разы быстрее обычных, но не журналируются (и не реплицируются).
> За меньшую скорость относительно таблиц mysql "только в памяти" снимается ограничение
> на размер. А также переживает не аварийный перезапуск сервера.
> Можно почитать здесь: http://www.depesz.com/2011/01/03/waiting-for-9-1-unlogged-ta.../ну то есть два разных механизма, как я и думал. по скорости "в разы быстрее" это преувеличение скорее всего, вот человек мерял http://michael.otacoo.com/postgresql-2/unlogged-table-perfor.../ и говорит о росте не более 20% на его задаче.
>вот человек мерял http://michael.otacoo.com/postgresql-2/unlogged-table-perfor... и говорит о росте не более 20% на его задаче.Так это общее ускорение ответа страниц, отработка запросов к таблицам постгреса ускоряется в разы, особенно при частых вставках.
> а они разве какое-то отношение к engine=memory имеют? мне всю дорогу казалось,
> что нетПрочитай документацию.
Тоже по этой причине на MySQL висит несколько проектов. Задавал этот вопрос у них на форуме, на что получил ответ - используй memcached. Вот только тогда поддерживать тогда надо не одну базу, а две, и перекидывать данные из одной в другую одним запросом, как это делается в случае MySQL, не получится.
Зачем?
Например есть данные, которые вообще нет необходимости писать в пзу, какие-нибудь данные онлайн, например список подключенных абонентов. В некоторых ситуациях можно добавлять и обновлять данные в таблице в памяти и из нее сохранять в таблицу на пзу через какой-то промежуток времени. Это не только ускоряет работу с базой, но и значительно увеличивает срок службы ssd. Таблица в памяти определенно нужная функция, иначеб ее не было в mysql
Бгг. "Нетранзакционный DDL - нужная функция, иначе б его не было в MySQL".
Далеко не всегда нужны ACID таблицы и транзакции. В моей практике часто встречались задачи, в которых потеря данных за час-два и даже день несущественна. Особенно учитывая редкость отключения электричества и использование ибп. А транзакции можно обеспечить и на memory движке, просто это осталось в разделе "недоделанное", как и тысячи других вещей.
http://lmgtfy.com/?q=DDL&l=1
Я для такого использую redis, а когда надо с ним заджойнить - redis FDW. Костыль, но отлично работает (только джойнить надо с CTE на foreign table, иначе redis на каждый id дергается).
Redis быстрая и очень гибкая СУБД. Postre и MySQL стоило бы поучиться у нее. Чего только стоит управляемое прозрачное кеширование в ram..., реляционных аналогов к сожалению не предвидется
отож.> 45% of acknowledged writes were thrown away. To add insult to injury, Redis preserved all the failed writes in place of the successful ones
Основной недостаток redis-а - персистенция через fork(): при большом потоке записей copy-on-write может раздуть процессы до срабатывания oom killer. overcommit_memory проблему решает, но костыль еще тот.
Всегда было:
http://www.databasesoup.com/2015/02/running-with-scissors-mo...
Зачем это? Реализовывать процедуры, которые будут в фоне на стороне базы работать?
Как вариант многопоточные хранимки, если например внутри хранимки надо сделать несколько тяжелых запросов, то их можно запустить параллельно
Два момента где многопоточность будет рулить:
1. неблокирующее чтение, в том числе с нескольких физических устройств сразу (для распределенных таблиц), возможно будет и упреждающее чтение
2. распараллеливание тяжелых запросов где грузится процессор (сортировка, GiST)