AT> То-есть смысл преследуется простой - если документ изменился, то это
AT> ведет к delete from index; insert into index (update в этом месте
AT> неприменим) т.е. в некоторый момент документа в индексе просто нет,
AT> а это плохо.
AT> Вторая причина - если коммитить реже, то это быстрее работает.
И на фришных базах (спасибо наелся) и у на промышленных
(а у нас честный Informix) ситуация у меня скажем "ровно обратная".
Длинные транзакции - смерть (для фришных баз) или "неоптимальная
производительность" (для промышленных)
Проверялось много раз на тупой задаче всасывания логов - транзакции
по 50 тыс записей идут заметно шустрее чем попытка всосать
лимон-другой записей за раз. (но по большому счету для таких
шуток есть HiPerformance Loader)
Если у тебя по базе болшая конкуренция запросов то ты запросто
при длинной транзакции создашь ступор залочив массу затронутых
транзакцией записей.
Кроме того у _любой_ базы есть противное понятие "long transaction"
Даже если оно явно не описано. Место под сохранение образов данных
"до изменения" что бы откатить если надо не безразмерное
--------------------------------------
Павел Яковлев
mailto: hac@citycat.ru ICQ 8085803 PPY-RIPN
технический директор PY125-RIPE
ЗАО "Интернет-Проекты"
--------------------------------------
"When God talks with me it's the miracle. When I talk with God it's the madness"
=============================================================================
= Apache-Talk@lists.lexa.ru mailing list =
Mail "unsubscribe apache-talk" to majordomo@lists.lexa.ru if you want to quit.
= Archive avaliable at =
