今天來講講在設計 API 常見的需求：分頁，為什麼要進行分頁？不外乎就是不希望向資料庫一次拿大量的資料出來，造成資料庫的負擔，且前端頁面也不應該一次顯示過多的大量資料，需要進行分頁來提升使用者體驗。
那麼在 Postgres 要實現分頁的需求其實有很多種方法，每個方法使用情境也都不一樣，其 performance 也會有差別的，這篇文章應該是我好久以前就寫好的草稿，但一直沒時間好好整理筆記發在 blog，所以就一直擱置了，因為分頁的需求很常見，所以是應該好好記下來才行。
今天分享這篇文章的筆記，主要內容是在講現在常見的程式語言的 memory model 的內容是什麼，因為我對 c/c++ 也很久沒碰了，所以可能我會理解錯誤，再歡迎指教。
今天分享這篇文章的相關筆記，該文章的作者也是主要 Go 的 contributor 其中之一。這篇文章主要是介紹硬體記憶體模型有什麼類型以及其差別。作者這系列的文章總共有三篇，前面兩篇都算是鋪陳第三篇的 Go 的記憶體模型設計，所以透過前兩篇文章先講講硬體記憶體模型是什麼及區別，第二篇是講講其他語言的記憶體模型設計為何。
如果有在用 GRPC 方式在做傳輸的話，就一定會知道 Google 推出的 Protocol Buffers (Protobuf)，其實它就是一種資料結構，現在 HTTP 傳輸大多使用 JSON 的格式來做資料傳輸，而 Protobuf 就是在做類似的事情。
今天來講講滿常會用的 errGroup 的用法及適用情境，為什麼好用呢？一般我們在用 goroutine 的時候都不能夠 return value，你要將 goroutine 執行後的結果傳出去，通常就要使用 channel 的方式才可以，而 errGroup 的套件則適用於如果你想要知道你開的 goroutine 執行的時候如果遇到 error 就停止工作，並且我需要知道 error value 的情況。
今天來談談 replication 最後的主題就是 Leaderless Replication。前面所說的都會有所謂的 Leader 去接收 Client 的 Write 的需求在同步給 Follower。 Leaderless Replication 盛行於 Amazon 的 Dynamo System，之後 Riak, Cassandra and Voldemort 這些 open source 也採用 leaderless replication，這些類型的資料庫被叫做 Dynamo-style。
Leaderless Replication 每個 Node 都是獨立的，也可以進行讀寫，這樣的架構在乎的倒也不是資料一致性，而是集群的可用性。
今天來講講 Ｍulti-Leader Replication 有哪些優缺點，以及如何處理 Write Conflicts。在前篇文章所提的 Leader-based replication，有個主要的缺點就是，如果這個 leader 掛了，所有的 writes 都無法進行了。因此這時候可以採用 multi-leader replication 的架構來解決這個問題，而每一個 leader 底下都會有各自的 follower。
今天來做 Replication 的筆記，主要是談在 Replication 中的模式，例如 Leaders and Followers 以及實現 Replication 有 Statement-based replication ，Logical replication，Physical replication 還有談談什麼是 Replication Lag 並造成了怎樣的影響。
今天來做 Modes of Dataflow 的筆記，重點圍繞著何謂 forward and backward compatibility，並且運用在 database，REST，RPC，Message-Passing 如何去克服向上相容及向下相容。
今天要來介紹的是 Copy Operation in Postgres 的用法，此外也比較與 Insert，Batch Insert 之間的速度比較。之所以想講這個是因為最近在工作上有需要大量 insert record 的需求，那因為是使用 Postgres 的關係，所以開始研究 Copy 的使用方式，並且深入探討了一下 Copy 使用 simple query 及 extended query protocol 請求方式的差別。這邊會透過 wireshark 來看封包分析一下～