如果是相同的語句執行時間不一樣,那就是有其他的會話在搶佔資源
About | Archive |
喜歡在地上滾的工程師
如果是相同的語句執行時間不一樣,那就是有其他的會話在搶佔資源
在 Rails 中其實可以實現串流下載,這樣當資料準備到多少,用戶就會下載到多少,當用戶中斷下載,執行的部分也會直接斷掉。
在 JavaScript 中的整數與浮點數其實都是屬用 Number 的數據類型,所有數字都是以 64 位浮點
很不幸運地,sidekiq 並不是一個非常可靠的 process。有時候會自己死掉,造成非常大的困擾。所以實務上還會需要額外再裝一個監控工具,如果發現它掛了,就自動重開它。
前端開發有可能會遇到一個問題,在前後端分離的狀況下,要再開發進行調試時,比方說希望從現在 Production 上的網域拿到 session 來做登入,或是拿後端的接口等問題,就
最近研究一個在 Postgres 奇怪的效能問題。
平常開發 Rails 在效能瓶頸時,除了會進 Database 測 explain 以外,也會在 console 裡面下同樣的語句。 不過遺憾的是,Rails 只能夠單純用 explain 而已,在 Postgres 中,如果僅僅只用 explain 分析
常理來說,unique index 在做查詢的時候,可以想像約等同於 `SELECT 1 AS one LIMIT 1`,因為不需花費力氣找尋其他相同的數據,所以理論上會快一些。
上一篇學習 什麼是 B-Tree 這篇就來補 B+ Tree 囉
一般像是 MySQL PostgreSQL 都是用 Btree 的方式建立索引。
最近把部落格搬家到靜態網站,用了 Hugo 架設的,包含圖床也都一併放到 S3, 這過程有點艱辛就記錄下來了,希望可以幫助到大家。
Postgres 在建立索引時,會阻塞 DML 也就是 lock 整個 table 的寫入(讀取則不影響),所以當需要對大資料量的 Table 打 index 時,會造成有 Downtime 時間,這在 Production 這種高並發的環境下是不適合的。
最近在分析影響效能的 Query,發現 PostgreSQL 有時的查詢效能不如我們預期,用了 EXPLAIN 下去分析索引,發現確實新增的 index 並沒有在 query plain 裡面,我想瞭解為什麼。
最近遇到了這麼個需求,需要針對狀態機內的 event 有的部分要 valiadte,有的部分則不需要,但是所有的 event 卻都要有 ActiveRecord 的 callback