的災難與慘痛經驗 》 The internet is full of awful advice of users suggesting you should turn off autovacuum, or run it manually at low traffic times, or simply adjust its schedule to run less often. To know why that’s ill-advised, you first need to understand the consequences of autovacuum not running. 網路上很多人建議關閉 AUTOVACUUM ,改以排程或手動 選擇負載低的期間執行 VACUUM 。但這是不明智的,你只 要知道不運行 AUTOVACUUM 會帶來的各種嚴重後果就會 明白了。 Ref: http://blog.getsentry.com/2015/07/23/transaction-id-wraparound-in-postgres.html
modifications to non-leaf pages (every modifications for the tree structure) required to exclude the other threads’ access to the whole index by X-lock, and every concurrent accessing the index tree were blocked.
http://dev.mysql.com/worklog/task/?id=6326 Ref#4: https://github.com/mysql/mysql-server/commit/070115a3d9548f790039c39a48b19d759ab2407c Before 5.7, every modifications to non-leaf pages (every modifications for the tree structure) required to exclude the other threads’ access to the whole index by X-lock, and every concurrent accessing the index tree were blocked. MySQL 開發者講了兩件事: 1. page split / merge “ 時,只有發生在 non-leaf pages” 時才會 whole index locked 。 2. page split / merge “ 時,只有在 non-leaf pages” ” 才稱 tree structure modification” 。 補充:這位 MySQL 開發者是誰? 1. 他是 Yasufumi Kinoshita 。 2. Percona 官方認證數一數二 InnoDB 專家,從事 InnoDB 內核改進多年。 ( 底下附參考連結 #2) 3. 本次的改良幾乎由他主導,是實際改程式碼的人。 ( 詳見下方參考連結 #3 及 #4) 4. 如果不相信他,我也不知道該相信誰。
9.2.3 vs. MySQL 5.6.10 17.3 本章小結 (p486) 對於子查詢的優化, PostgreSQL 和 MySQL 各有所長;對於等價謂詞 重寫,條件的處理, MySQL 略勝 PostgreSQL 一籌,在各種連接消除方面 ,二者基本相當,都支持外連接消除和嵌套連接消除。在索引和約束的利用 方面,尤其是語義優化和非 SPJ 的優化, MySQL 顯得技高一籌;對於索引 和約束以及條件化簡的充分利用,使得 MySQL 能及早把計算和推理的工作 在查詢計劃生成的過程中完成,從而生成更為高效的查詢執行計劃。 整體上, MySQL 查詢優化器支持的邏輯優化點比 PostgreSQL 多, MySQL 查詢優化器邏輯查詢優化部分靈光閃爍,讓讀之者愛不德手,但這 不代表查詢優化器的效率高於 PostgreSQL 。查詢優化器的效率高低需要 在現實中根據實際場景通過測試來評估。
only tuple") 。 但 HOT 並沒有完全解決問題,它的缺點如下: 1. 只有在所有索引屬性都沒有被更新時才能使用 HOT 。 2. 只有在被更新記錄所在頁面能夠存儲新版本時才能用 HOT 。 Ref: http://rhaas.blogspot.tw/2011/02/mysql-vs-postgresql-part-2-vacuum-vs.html