Repository navigation
Conversation
Codex Review Summary: ✅ CompletedThis comment shows the latest Codex review activity on this pull request.
ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings. |
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 7c76ce808e
ℹ️ About Codex in GitHub
Your team has set up Codex to 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 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| ] | ||
|
|
||
| # Run at the execution boundary: later calculations can reuse an existing join. | ||
| def prune(query) do |
There was a problem hiding this comment.
have we benchmarked this? I hesitate to do something that makes the SQL smaller and take a non-trivial performance hit on all queries. I'm wondering if this could be "built up" while we build the query instead of done as a pass at the end to avoid the cost of re-traversal.
There was a problem hiding this comment.
I tried collecting required columns during query construction and opened #282 with that implementation.
I've also updated the benchmark to compare upstream, this PR, and the new implementation, including query construction costs. For the latest Payment query, the new implementation uses about 1.6% more caller-process reductions than upstream and 4.6% fewer than this version. Wall times varied between runs, so I'm not claiming a runtime speedup.
Prune unused columns from implicit
from_many?subquery selections. Preserve explicit selections and whole-row references.For example, an invoice query reads the latest payment's
statusandpaid_at, but the lateral subquery selects all 20 payment columns. This change narrows the selection while preserving references from enclosing scopes. Joins, nesting, filtering and ordering are unchanged.PostgreSQL already optimizes away these unused projections. The main motivation is to make generated SQL easier to inspect while debugging. Other SQL backends may also benefit, though that has not been measured.
ash-project/ash_postgres#919 applies pruning immediately before query execution.
I've put together a runnable example with formatted before/after SQL.
Contributor checklist
Leave anything that you believe does not apply unchecked.