@lotics/app-sdk 0.51.0 → 0.51.1
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/docs/queries.md +9 -0
- package/package.json +1 -1
package/docs/queries.md
CHANGED
|
@@ -784,6 +784,15 @@ filter is for caller-driven refinement, not for the main cut (a runtime-only fie
|
|
|
784
784
|
managed index). (The engine pushes eligible filter-over-union predicates down automatically,
|
|
785
785
|
but don't rely on that for other shapes.)
|
|
786
786
|
|
|
787
|
+
**Sorted, paginated unions are index-served — write them plainly.** A `limit(sort(union(project(from_table) …)))`
|
|
788
|
+
register (the "search all three tables, sort by one column, paginate" shape) is compiled to push
|
|
789
|
+
`ORDER BY … LIMIT` into each arm and `MergeAppend` the per-arm sort-index scans — it does **not**
|
|
790
|
+
scan every arm whole and heap-sort the union. So a single-key sort over a union of tables, each
|
|
791
|
+
projecting that key as a direct field passthrough, is fast at any size. Don't hand-split it into
|
|
792
|
+
per-table queries you merge client-side; the merge already happens in the index. (Requires the
|
|
793
|
+
sort key to be a bare field projection — a computed/literal/type-overridden sort column falls back
|
|
794
|
+
to the whole-union sort.)
|
|
795
|
+
|
|
787
796
|
### The authoring rules
|
|
788
797
|
|
|
789
798
|
1. **Filter at the source.** Push every static predicate into `from_table.filter`.
|