使用'Commit Retaining'是否會影響Firebird性能？

Question

下面引用的摘錄似乎在這一點上是矛盾的。

（他們都是很老，我認爲，第二個是從2004年第一個提到的Borland所以必須是老一樣，所以也許他們是過時的。）

第一似乎表明，提交保留保持交易活躍，從而堅持OIT。第二，如果我理解它意味着在提交保留的情況下，現有的TID被標記爲已提交，並且事務保持活動狀態，但具有新的TID，因此不會粘住OIT。這第二個摘錄與Interbase有關，我不知道這是否能解釋看似矛盾。

Firebird Documentation提取物：

隨着火鳥（和InterBase的），提交保留導致事務 保持有趣下去。垃圾收集在「標準」Borland RAD工具數據庫應用程序和使用提交保留的任何其他 應用程序上有效地停止 。

Embarcadero Blog post提取

讀取已提交，讀寫：

本次交易能夠永遠沒有負面影響的 性能，如果你做了承諾保留不時運行。

Answer 1

當您使用提交保留（使用的API或COMMIT RETAIN）與火鳥，在開始交易並沒有真正結束，它只是被從一個新的交易已經在內部開始了一組可見交易的相關，同時也保持舊的活動。

這意味着最舊的有趣和最舊的活動交易不會移動，並且後面的版本會累積起來，直到交易真正落實才能被垃圾收集。這意味着最終查詢將需要掃描更長的記錄版本鏈，這可能會對性能產生影響。

我假設可能有一些優化，例如，如果沒有在事務中啓動的遊標打開，則原始事務可能被標記爲已提交（保留提交的功能之一是遊標未關閉在事務提交時，如果我沒有弄錯 - 要求舊的事務上下文保持可用）。這可能是InterBase爲讀取提交事務所做的事情。

這可以通過啓動isql會話並結合提交保留做一些插入：如果您組合檢查gstat -h，您會注意到，最早的有趣和最舊的活動事務不會移動，直到您真的承諾。