Для владельца авто с ДВС обогрев бесплатный, ему не важно в результате чего. Если смотреть с точки зрения выбора автомобиля, то совершенно справедливо, в этом смысле можно говорить об огромном преимуществе углеводородного источника энергии для обогрева над аккумуляторным электричеством.
Справедливости ради, карта климата на самом деле разыграна 4 раза. В холодном автомобиле зимой никто не ездит и если у автомобиля с ДВС обогрев фактически бесплатный, то электромобиль зимой представляет собой плохо теплоизолированное помещение с дорогим электрическим обогревом.
Помню, проходил я подобные уроки скорочтения в молодости, лет 25 назад, по почте присылали.
Подтверждаю, работает, десяток страниц и больше в минуту можно читать легко, с запоминанием основной информации. Но запоминание специфическое- рассказать содержание статьи или книги сможешь, а отдельные пункты или мысли, когда понадобятся, не всплывут. Видимо, не устанавливаются ассоциативные связи с информацией из других источников.
В-общем, очень полезный навык для секретаря крупного политического деятеля, больше не знаю зачем.
Наоборот, синхронное выполнение обусловлено наличием общих данных. Именно использование общих данных определяет точки синхронизации.
Oracle тоже видимо позволяет в автономной транзакции менять данные основной, во всяком случае пакет скомпилировался. Но ни Oracle ни Firebird не заставляют так делать, это плохая практика на любой платформе, модель акторов создавалась чтобы этого избежать.
А писать синхронный параллельный код для сервера БД — это уж эпическая криворукость. Каждая транзакция должна делать свою часть работы — изменение общих переменных или возможность изменения одних и тех же строк таблицы разными транзакциями должны быть исключены.
Если выполнение асинхронное команд ожидания/синхронизации как правило нет. Если параллельные цепочки транзакций должны выдать согласованный результат обычно используется управляющий процесс, следящий за работой других процессов.
MapReduce устроен именно так — процедуры Map и Reduce полностью асинхронны, мастер-процесс следит, когда Map подготовят файл с данными, его начинают обрабатывать Reduce.
Не понял, при чем тут «полностью синхронно». Код после begin в автономной транзакции выполняется параллельно основному процессу и, если без криворукости, полностью асинхронно. Никаких блокировок не предполагается.
Разделяю их радость, кое что свое тоже перевел. Думаю, что основной предмет радости все-таки в том, что достаточно легко перевелось. Если бы биллинг сотового оператора федерального уровня (может это не тот, у которого интернет-магазин) взялись переводить на PostgreSQL, его разработчикам было бы не до радости.
Желание «обходить» транзакции возникает в основном как раз для логирования выполнения, что тоже не плохо (удобнее чем писать во внешний файл, хотя не обязательно надежнее).
Но принципиальнее использование автономных транзакций для запуска параллельных процессов обработки данных. Например, использовал такой подход для сборки больших хранилищ данных. Кстати, по принципу очень похож на современный Map Reduce в Big Data, только внутри распределенной базы Oracle.
Правильно ли распареллеливать обработку задачи на уровне сервера БД или на уровне сервера приложений? Спорный вопрос, часто все зависит от посторонних организационных факторов. Говнокод в смысле ненадежного, трудно поддерживаемого кода встречается в обоих вариантах как и надежный код.
Без обид, мне очень нравится, что вы натворили как свободные художники, и перечисленые проекты хороши и Постгресом я с удовольствием для себя пользуюсь. Меня только огорчает, что вы не отправили Оракл на помойку, хотя, мне кажется, могли бы.
А для этого не хватает как раз вложенной транзакционности, потому что без нее не любой оракловый проект можно мигрировать. Последнее что я слышал об автономных транзакциях в PostrgreSQL это добавление «подтранзакций», но это как раз, в основном, для логирования и годится (буду рад, если планы поменялись).
Конечно при разработке нового проекта без множественной транзакционности можно обойтись: сервер приложений, например, может распараллелить пользовательскую сессию. Но вы точно выиграете когда старые проекты можно будет мигрировать без изменения архитектуры.
То есть, вы утверждаете, что Oracle нельзя использовать «в хоть сколь-либо серьёзных задачах»? Странно только, что некоторые компании предпочитают платить Ораклу 20 K$ на ядро (примерно) чем брать бесплатный PostgreSQL.
А если серьезно, я вот о чем говорю. Допустим есть проект на Оракле, где для распараллеливания обработки пользовательской сессии используются автономные транзакции, тогда, если дело не ограничено простым логированием, вы на PostgreSQL без изменения архитектуры уже не переползете, а вот на новый Firebird, наверняка не без проблем, но, в принципе, можно.
Вообще в плане импортозамещения Оракла заявка мощная. PostgreSQL не потянул, ребята больше увлекались всякими рюшечками, архиудобными типами данных и прочими, а фундаментальные вещи типа автономных транзакций упущены.
Из текста не понятно, в какие именно версии Postgresql внедрены эти очень полезные оптимизации.
Вспомнилось что в советской науке существовал такой термин: "мелкотемье".
Для владельца авто с ДВС обогрев бесплатный, ему не важно в результате чего.
Если смотреть с точки зрения выбора автомобиля, то совершенно справедливо, в этом смысле можно говорить об огромном преимуществе углеводородного источника энергии для обогрева над аккумуляторным электричеством.
Справедливости ради, карта климата на самом деле разыграна 4 раза. В холодном автомобиле зимой никто не ездит и если у автомобиля с ДВС обогрев фактически бесплатный, то электромобиль зимой представляет собой плохо теплоизолированное помещение с дорогим электрическим обогревом.
Подтверждаю, работает, десяток страниц и больше в минуту можно читать легко, с запоминанием основной информации. Но запоминание специфическое- рассказать содержание статьи или книги сможешь, а отдельные пункты или мысли, когда понадобятся, не всплывут. Видимо, не устанавливаются ассоциативные связи с информацией из других источников.
В-общем, очень полезный навык для секретаря крупного политического деятеля, больше не знаю зачем.
Oracle тоже видимо позволяет в автономной транзакции менять данные основной, во всяком случае пакет скомпилировался. Но ни Oracle ни Firebird не заставляют так делать, это плохая практика на любой платформе, модель акторов создавалась чтобы этого избежать.
А писать синхронный параллельный код для сервера БД — это уж эпическая криворукость. Каждая транзакция должна делать свою часть работы — изменение общих переменных или возможность изменения одних и тех же строк таблицы разными транзакциями должны быть исключены.
Если выполнение асинхронное команд ожидания/синхронизации как правило нет. Если параллельные цепочки транзакций должны выдать согласованный результат обычно используется управляющий процесс, следящий за работой других процессов.
MapReduce устроен именно так — процедуры Map и Reduce полностью асинхронны, мастер-процесс следит, когда Map подготовят файл с данными, его начинают обрабатывать Reduce.
Но принципиальнее использование автономных транзакций для запуска параллельных процессов обработки данных. Например, использовал такой подход для сборки больших хранилищ данных. Кстати, по принципу очень похож на современный Map Reduce в Big Data, только внутри распределенной базы Oracle.
Правильно ли распареллеливать обработку задачи на уровне сервера БД или на уровне сервера приложений? Спорный вопрос, часто все зависит от посторонних организационных факторов. Говнокод в смысле ненадежного, трудно поддерживаемого кода встречается в обоих вариантах как и надежный код.
А для этого не хватает как раз вложенной транзакционности, потому что без нее не любой оракловый проект можно мигрировать. Последнее что я слышал об автономных транзакциях в PostrgreSQL это добавление «подтранзакций», но это как раз, в основном, для логирования и годится (буду рад, если планы поменялись).
Конечно при разработке нового проекта без множественной транзакционности можно обойтись: сервер приложений, например, может распараллелить пользовательскую сессию. Но вы точно выиграете когда старые проекты можно будет мигрировать без изменения архитектуры.
А если серьезно, я вот о чем говорю. Допустим есть проект на Оракле, где для распараллеливания обработки пользовательской сессии используются автономные транзакции, тогда, если дело не ограничено простым логированием, вы на PostgreSQL без изменения архитектуры уже не переползете, а вот на новый Firebird, наверняка не без проблем, но, в принципе, можно.