>> AT> Вторая причина - если коммитить реже, то это быстрее работает.
>> И на фришных базах (спасибо наелся) и у на промышленных
>> (а у нас честный Informix) ситуация у меня скажем "ровно обратная".
>> Длинные транзакции - смерть (для фришных баз) или "неоптимальная
>> производительность" (для промышленных)
AT> На PostgreSQL 7.1.3
AT> - одна длинная транзакция лучше (быстрее) кучи мелких
ну может в 7.1.3 и стало
когда я проверял было фиг (но еще раз подчеркну на _моей_ задаче)
AT> - длина транзации ограничена местом на диске
а я и про написал
AT> 50 тыс записей против 1 млн я не рассматривал, рассматривается
AT> десятки тысяч против десятков :)
так тогда у тебя НЕ длинная транзакция а так, погулять вышел ;)
>> Кроме того у _любой_ базы есть противное понятие "long transaction"
>> Даже если оно явно не описано. Место под сохранение образов данных
>> "до изменения" что бы откатить если надо не безразмерное
AT> Да, конечно. Аналогично, у _любой_ базы есть практическое ограничение
AT> связанное с местом на дисках - но его мы тоже сейчас не рассматриваем
а то ;)
вопчем СУБД пока единственное что меня во "самодельных"
продуктах разочаровало, все остальное - хорошо
--------------------------------------
Павел Яковлев
mailto: hac@citycat.ru ICQ 8085803 PPY-RIPN
технический директор PY125-RIPE
ЗАО "Интернет-Проекты"
--------------------------------------
"God is real, unless declared integer"
=============================================================================
= Apache-Talk@lists.lexa.ru mailing list =
Mail "unsubscribe apache-talk" to majordomo@lists.lexa.ru if you want to quit.
= Archive avaliable at =
