Вот в том то и проблема, что критериев я таких придумать не могу. Но я абсолютно не согласен с утверждением про количество задач. У каждой СУБД есть свои слабые и сильные места, обусловленные, к примеру, архитектурой СУБД. Из-за этого под каждую СУБД разрабатывают приложения по-разному. И именно поэтому не имеет смысла проводить какие-то атомарные тесты, они ничего вам не дадут.
Например, MSSQL — блокировочная субд, а Oracle — мультиверсионник. Это два разных подхода, каждый из которых, обладая своими сильными и слабыми сторонами, влечет за собой разный подход к разработке.
Нет, я то про них знаю, но я технический специалист. А предположим, что я CEO какого-нибудь «НЕФТЕТРАНСГАЗОСОС».
У меня есть mission-critical система «НЕФТЕТРАНСГАЗОБИЛЛ (тм)», которая может работать на Oracle или на Postgresql. За минуту простоя мы теряем 100к$.
И я не понимаю, с кем мне договор на поддержку подписывать? С EnterpriseDB или с Postgresmen? Тогда зачем мы здесь вообще об EnterpriseDB заговорили, раз они не могут поддержки mission-critical систем в РФ организовать.
Если речь идет о РФ, то есть ли у EnterpriseDB партнеры, которые могут осуществлять поддержку прямо здесь? Или я должен буду себе специалиста из заграницы выписывать?
Хотите я вам так ее померяю, что будет разница 100%? Я пока не видел ни одного сколько-нибудь объективного теста. И, честно сказать, не уверен что объективные тесты вообще возможны при сравнении производительности СУБД.
Еще есть один фактор — специалистов по open source СУБД сейчас намного меньше, чем по популярным проприетарным субд. Это, конечно, дело наживное, но нужен некоторый толчок чтобы все сдвинулось с мертвой точки.
Да, pgagent не радует. Этот его 2-х минутный период сильно обламывает, не понимаю что им мешает добавить секунды в шедулер.
А насчет c-функции — мне логи все-таки хочется видеть в таблице. Это, конечно, вопрос вкуса, но мне например лень лезть в шелл и грепать файл вместо того, чтобы написать селект.
dblink_exec работает медленно из-за того, что создается новое соединение с БД — а это процесс намного более дорогостоящий чем простая запись в таблицу. Поэтому использовать необходимо с умом. Приведу пример: предположим ваша функция состоит из следующих шагов: начало, большой длинный цикл, конец, обработка ошибок.
Вы логируете начало, конец и обработку ошибок с уровнями логирования «INFO» и «ERROR», а внутри цикла с уровнем «DEBUG». Чтобы функция работала как можно быстрее, вы можете отключить логирование с уровнем «DEBUG» (доработать функцию «log» для такого поведения не составит большого труда), и включать логирование «DEBUG» только если приперло и необходимо какое-то серьезное разбирательство.
То есть вы можете избежать потерь производительности просто с умом применяя этот прием, на это я и хотел обратить внимание в конце топика.
Вы сейчас о конкретной задаче, применение автономных транзакций много шире. Конечно же вы можете логировать разными способами и обходить описанную проблему по-разному. Просто savepoint и автономные транзакции это разные вещи, они никак не связаны.
Например, MSSQL — блокировочная субд, а Oracle — мультиверсионник. Это два разных подхода, каждый из которых, обладая своими сильными и слабыми сторонами, влечет за собой разный подход к разработке.
P.S. howfuckedismydatabase.com/
У меня есть mission-critical система «НЕФТЕТРАНСГАЗОБИЛЛ (тм)», которая может работать на Oracle или на Postgresql. За минуту простоя мы теряем 100к$.
И я не понимаю, с кем мне договор на поддержку подписывать? С EnterpriseDB или с Postgresmen? Тогда зачем мы здесь вообще об EnterpriseDB заговорили, раз они не могут поддержки mission-critical систем в РФ организовать.
P.S. Вы ж уточняйте что речь идет 30 тысяч долларов, а то вдруг кто не поймет.
На основе Lucene построен Solr, который как раз и является прямым конкурентом Sphinx.
А насчет c-функции — мне логи все-таки хочется видеть в таблице. Это, конечно, вопрос вкуса, но мне например лень лезть в шелл и грепать файл вместо того, чтобы написать селект.
Спасибо что указали на это, действительно важный момент.
Вы логируете начало, конец и обработку ошибок с уровнями логирования «INFO» и «ERROR», а внутри цикла с уровнем «DEBUG». Чтобы функция работала как можно быстрее, вы можете отключить логирование с уровнем «DEBUG» (доработать функцию «log» для такого поведения не составит большого труда), и включать логирование «DEBUG» только если приперло и необходимо какое-то серьезное разбирательство.
То есть вы можете избежать потерь производительности просто с умом применяя этот прием, на это я и хотел обратить внимание в конце топика.