Use proper result set when evaluating parameters - #782
Conversation
|
| } | ||
|
|
||
| for (let i = 0; i < this.lookupStages.length; i++) { | ||
| // Within a stage, we can resolve lookups concurrently. |
There was a problem hiding this comment.
With the implementation from this PR, joins are no longer processed concurrently. It's possible to add that back with minor added complexity, but:
- this is only relevant for complex sync streams
- we already evaluate other users / queriers concurrently, to the point where bucket storage is likely the bottleneck and not JS
So I don't think this is necessarily something worth doing, but I can change this here / in a follow-up PR if needed.
|
@codex review |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 68a4c2dc8b
ℹ️ About Codex in GitHub
Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: af866d1014
ℹ️ About Codex in GitHub
Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".
rkistner
left a comment
There was a problem hiding this comment.
Codex picked up a performance regression here with intersecting results. Example queries:
-- In this case we can intersect results
SELECT * FROM issues
WHERE id IN auth.parameter('allowed_issue_ids')
AND id IN subscription.parameter('visible_issue_ids')
AND id IN subscription.parameter('selected_issue_ids');
-- In this case we can compute the checks independently
SELECT * FROM issues
WHERE 'issues' IN auth.parameter('tables')
AND 'read' IN auth.parameter('permissions');With the old implementation, the intersection was computed first. The new implementation builds up the Cartesian product of the arrays before filtering them. In a cases like the above, the number of results can explode even with modestly-sized arrays, leading to slow performance and/or OOM-crashes.
dade362 to
849a419
Compare
|
That is a good point. Since the columns of intersections are known statically, we can evaluate them for each row added to the result set instead of removing rows after building the cartesian product. |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 849a419d50
ℹ️ About Codex in GitHub
Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".
rkistner
left a comment
There was a problem hiding this comment.
I like the approach of using a ResultSet here, but Codex picked up another couple of performance regressions with the implementation (manually confirmed the findings).
| for (const row of rows) { | ||
| if (!filter(originalRow, row)) { | ||
| continue; | ||
| } |
There was a problem hiding this comment.
The memory usage is now only O(N) instead of the O(N^2) before, but the comparisons are still O(N^2) here.
This affects the same query example mentioned before:
SELECT * FROM issues
WHERE id IN auth.parameter('allowed_issue_ids')
AND id IN subscription.parameter('visible_issue_ids')
AND id IN subscription.parameter('selected_issue_ids');There was a problem hiding this comment.
This is tricky to optimize in ResultSet because it also needs to work for async joins from parameters (where we at least know we have a constant upper bound due to the paramer limit...).
To avoid pathological cases for parameter-based intersections, I'll look into optimizing those specifically in the evaluator.
| for (const toDelete of deletedRows) { | ||
| this.#rows.splice(toDelete - offset, 1); | ||
| offset++; | ||
| } |
There was a problem hiding this comment.
Array.splice() is O(N) on the array size, making this loop O(N^2).
When querying buckets for Sync Streams, we generally try to resolve parameters independently to form a cartesian product in the end. This is correct for most streams, but goes wrong when a parameter index has more than one column. For example, in
SELECT a.* FROM a, b WHERE a.c1 = b.c1 AND a.c2 = b.c2 AND b.u = auth.user_id(), the two parameters areb.c1andb.c2. If we encounter multiple rows ofbthrough a lookup result, we can't assume those to be independent parameters though! We can only pair parameters that originate from the same row.This is currently implemented by tracking provenance for each parameter value back to the lookup this originally came from. When we build the cartesian product in the end, we ignore values with incompatible provenance from different rows. Unfortunately, tracking provenance is both kind of expensive and very tricky to get right.
Semantically, evaluating bucket parameters involves:
This replaces the previous querier logic with an actual result set implementation: We start out with a unit set of one row without columns, then go through added lookups that are cross-joined (table-valued functions) or inner-joined (parameter lookups). If we end up with an empty intermediate result set at any point, we know there won't be any buckets and bail out early.
Intersection parameters require special consideration now, but can be implemented by going through the result set and deleting rows where the columns don't match.
AI use: The approach is manual, most tests and some implementation details are generated with Claude Code.