拜讀後，受老唐啟發，想出下面一些問題，也許能進一步驗證Pg和MySQL的效能。

1 目的：這除了對比2者UPDATE命令的效能外,更進一步考察2者整體效能.

2 為什麼說可以進一步考察2者整體效能呢? 這是因為:
2.1 大量UPDATE操作,可以造成大量垃圾資料(Pg和MySQL都使用了MVCC機制來應對併發訪問,只是Pg缺少MySQL的回滾段機制,致使UPDATE後垃圾元組不斷增多.UPDATE相當於加邏輯刪除標誌並在新位置插入"新元組")
2.2 在垃圾元組不斷增多的情況下, Pg的IO總量會上升, 這樣資料快取的失效可能性將增加
2.3 因此Pg的效能可能受到相比MySQL而言更大的影響(MySQL及時回收回滾段,Pg需要Vacuum定時清理垃圾元組,這樣會因鎖元組增加併發衝突可能並不如回滾段清理及時且減少衝突機會)

3 如果能在老唐的本次測試基礎上,繼續進行如下的測試,則更好且更能發現問題/說明問題.
3.1 統計測試前(已經載入好初始資料)資料的外存大小,設為t_init
3.2 各個資料庫的資料緩衝區設定不大於初始資料大小,如設為30%--60%等
   (為的是考察磁碟類資料庫常規環境下Pg和MySQL的效能情況,如果資料全部能載入的記憶體,則對比[MVCC+回滾段+快取置換]對"系統長期執行的影響"沒有意義)
3.3 根據指令碼(update_non_index_commit_pg2.lua/update_non_index_commit_mysql.lua),預估更新的資料量,設為t_updated.
    如果能多次測試，把這個更新量設為初始量t_init的10%，20%，50%，100%，150%，200%，直到500%或更大一點，則更容易通過對比找出問題
3.4 統計測試結束後(已經被更新後全部刷出記憶體的物理儲存資料)資料的外存大小,設為t_result  
3.5 分別在以上基礎上增加綜合性強的其他測試，如寫多（TPC-C）或讀多（TPC-H）測試（當然使用另外的資料集，需要檢查這樣的資料集所佔的資料量有多少，如果較少如佔比20%，則忽略不計，但注意靈活分析，確定是否可以忽略）
3.6 進行統計（可有你自己的關注點和統計方式。sysbench提供的統計結果需要參照，但不是本文重點）
    對於TPC-C：x軸為t_result，y軸3.5中得到的流量指標（Throughput,簡稱tpmC)
    對於TPC-H：x軸為t_result，每個t_result上的點為Q1到Q22，y軸3.5中得到的TPC-H中22條QUERY語句的值
3.7 觀察結果，看看有什麼不同？
    ^_^, 老唐要是能辛勤奉獻這樣的結果，則是一大幸事。提前感謝老唐！^_^
3.8 另外，可以觀察在TPC-C/TPC-H背景下，Pg和MySQL的隨機更新能力(換個角度分析)。 

3.9 期待有朋友能提供測試資料... ^_^   
   
其他
1 sysbench指令碼與資料庫伺服器所在機器獨立部署
2 原文說：
  在MySQL的測試過出現過MySQL伺服器hang住的情況，出現這種情況後，無法做任何更新，過一會會恢復，但再過一會還會在hang住。上面的測試結果是取其中沒有hang的情況。
  ---可以取更長的時間段，不用把hang住的情況去掉，這樣測試結果能更為客觀地表明真是情況。
3 如上測試場景設計，綜合性較強（[MVCC+回滾段+快取置換]+TPC-C/TPC-H），故較為貼近Pg和MySQL的整體效能實際。
4 進一步細化，可以考慮UPDATE如下的情況：
------+--------+----------------------------+----------
對比項 |主鍵列   | second index列(非唯一)      | 非索引列
------+--------+----------------------------+----------
MySQL |        + 設定insert buffer相關引數    |
------+--------+----------------------------+----------
Pg    +        |                            |
------+--------+----------------------------+----------
5 日誌檔案的大小和日誌快取的大小，不宜過大，參照生產環境的實際情況設定
6 資料檔案和日誌檔案可以分散到不同的物理介質