Some operator lists read the database once per row #10

New Issue

2026-09-21T07:18:04Z

cgalo5758 commented

2026-09-21 07:18:04 +00:00

What a contributor runs into

A page's row builder calls a single-record query inside the loop over the page's rows, so a page of fifty rows costs fifty-odd reads where one batch read would do. Known instances: the organization page's tier-change rows resolve the acting person one row at a time, and the ladder per row rather than per ladder; the landing page's activity feed resolves an organization name and a person name per event; and any list whose rows carry a name resolved from an identifier. Two are already gone, the products list's per-product readiness reads and its entitlement-set name lookup, now four batch queries for the whole page.

Why it costs

Nothing shows at demo scale, so the pattern keeps being copied into the next list. The day a deployment has a thousand people it is in a dozen builders at once, each one a separate fix, and the pages that slow down first are the ones an operator opens every day.

Where

internal/server, the list and ledger builders; the query files of the schemas they read.

Done when

Every handler has been checked for a single-record query inside a loop over rows; each one found is replaced with a batch query taking an array of identifiers, the idiom the entitlement-set queries already use, and a map in Go; a test pins the number of queries per page for each list touched; and the single-record query stays where a detail page is its only caller.

Migrated from status/issues.md at b7a0e15

## What a contributor runs into A page's row builder calls a single-record query inside the loop over the page's rows, so a page of fifty rows costs fifty-odd reads where one batch read would do. Known instances: the organization page's tier-change rows resolve the acting person one row at a time, and the ladder per row rather than per ladder; the landing page's activity feed resolves an organization name and a person name per event; and any list whose rows carry a name resolved from an identifier. Two are already gone, the products list's per-product readiness reads and its entitlement-set name lookup, now four batch queries for the whole page. ## Why it costs Nothing shows at demo scale, so the pattern keeps being copied into the next list. The day a deployment has a thousand people it is in a dozen builders at once, each one a separate fix, and the pages that slow down first are the ones an operator opens every day. ## Where [`internal/server`](https://git.coopcloud.tech/wiki-cafe/member-console/src/commit/b7a0e15/internal/server), the list and ledger builders; the query files of the schemas they read. ## Done when Every handler has been checked for a single-record query inside a loop over rows; each one found is replaced with a batch query taking an array of identifiers, the idiom the entitlement-set queries already use, and a map in Go; a test pins the number of queries per page for each list touched; and the single-record query stays where a detail page is its only caller. Migrated from status/issues.md at b7a0e15

cgalo5758 added the

kind

debt

area/identity area/billing area/operator-ui labels 2026-09-21 07:18:04 +00:00

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: wiki-cafe/member-console#10