Simon Riggs wrote:
> Multiple backends waiting while we perform a write. Commits then happen
> as a group (to WAL at least), hence Group Commit.
The problem with our current commit protocol is this:
1. Backend A inserts commit record A
2. Backend A starts to flush commit record A
3. Backend B inserts commit record B
4. Backend B waits until 2. finishes
5. Backend B starts to flush commit record B
Note that we already have the logic to flush all pending commit records
at once. If there's also backend C that insert their commit records
after step 2, B and C will be flushed at once:
1. Backend A inserts commit record A
2. Backend A starts to flush commit record A
3. Backend B inserts commit record B
4. Backend B waits until 2. finishes
5. Backend C inserts commit record C
6. Backend C waits until 2. finishes
5. Flush A finishes. Backend B starts to flush commit records A+B
The idea of group commit is to insert a small delay in backend A between
steps 1 and 2, so that we can flush both commit records in one fsync:
1. Backend A inserts commit record A
2. Backend A waits
3. Backend B inserts commit record B
3. Backend B starts to flush commit record A + B
The tricky part is, how does A know if it should wait, and for how long?
commit_delay sure isn't ideal, but AFAICS the log shipping proposal
doesn't provide any solution to that.
-- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com
