From 0119806204a2390562a1753c9641632e6179635b Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Fredrik=20Adel=C3=B6w?= Date: Wed, 20 May 2026 16:29:17 +0200 Subject: [PATCH] Update changeset to document totalItems semantic fix MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Co-Authored-By: Claude Opus 4.6 (1M context) Signed-off-by: Fredrik Adelöw --- .changeset/split-query-entities-count.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/.changeset/split-query-entities-count.md b/.changeset/split-query-entities-count.md index de5cb40e43..4a0ac5492d 100644 --- a/.changeset/split-query-entities-count.md +++ b/.changeset/split-query-entities-count.md @@ -3,3 +3,5 @@ --- Split the `queryEntities` list and count into separate queries instead of a multi-reference CTE. When the `filtered` CTE was referenced twice (once for the count, once for the data), PostgreSQL refused to inline it, forcing full materialization of the filtered set before applying `LIMIT`. By running the count as a standalone query, the list CTE is only referenced once, allowing the planner to short-circuit on `LIMIT` and return the first page in milliseconds instead of waiting for the full filtered set to materialize. + +The standalone count query also fixes a pre-existing bug where `totalItems` was inflated for entities with multi-valued sort fields (e.g. tags). The old CTE-based count counted search rows, so an entity with 3 tags would be counted 3 times. The new count uses `EXISTS` to count distinct entities, aligning `totalItems` with the number of entities actually reachable through cursor pagination.