Skip to content

refactor(query_engine_context): remove rw result from context field - #1418

Draft
jkaczman wants to merge 2 commits into
mainfrom
jk-sg-remove-rw-result-from-context
Draft

refactor(query_engine_context): remove rw result from context field#1418
jkaczman wants to merge 2 commits into
mainfrom
jk-sg-remove-rw-result-from-context

Conversation

@jkaczman

@jkaczman jkaczman commented Aug 24, 2026

Copy link
Copy Markdown
Contributor

Starting to restructure RewriteResult to become a "Query Planner";

As part of our goal to support more "multi-query" queries such as subselects and CTEs, as well as supporting better EXPLAIN output, we need an intermediate step between parsing and execution that creates a proper "Query Plan".

After going through the code and poking it a few different ways, we determined that the best place to live is what is currently called RewriteResult, and what we expect to eventually call QueryPlanner. Our long term goal is to have this take the query engine context as an argument, and return the abstract steps required, those steps being the query to be run (with subqueries replaced with placeholders), and the route it is going to be run on.

As we're promoting this to a "thing that does the thing", it no longer makes conceptual sense to have it live on QueryEngineContext, as it's not context. Additionally, we intend to eventually have this start to hold onto borrowed data, and adding an additional lifetime to QueryEngineContext will affect much more code than what is necessary for this refactor.

Co-authored-by: Sage <sagetheprogrammer.com>

Starting to restructure RewriteResult to become a "Query Planner";

As part of our goal to support more "multi-query" queries such as subselects and
CTEs, as well as supporting better EXPLAIN output, we need an intermediate step
between parsing and execution that creates a proper "Query Plan".

After going through the code and poking it a few different ways, we determined
that the best place to live is what is currently called RewriteResult, and what
we expect to eventually call `QueryPlanner`. Our long term goal is to have this
take the query engine context as an argument, and return the abstract steps
required, those steps being the query to be run (with subqueries replaced with
placeholders), and the route it is going to be run on.

As we're promoting this to a "thing that does the thing", it no longer makes
conceptual sense to have it live on QueryEngineContext, as it's not context.
Additionally, we intend to eventually have this start to hold onto borrowed
data, and adding an additional lifetime to QueryEngineContext will affect much
more code than what is necessary for this refactor.
@jkaczman
jkaczman requested review from levkk and sgrif August 24, 2026 17:43
@codecov

codecov Bot commented Aug 24, 2026

Copy link
Copy Markdown

Codecov Report

❌ Patch coverage is 96.00000% with 1 line in your changes missing coverage. Please review.

Files with missing lines Patch % Lines
pgdog/src/frontend/client/query_engine/set.rs 50.00% 1 Missing ⚠️

📢 Thoughts on this report? Let us know!

@sgrif
sgrif marked this pull request as draft August 24, 2026 17:59
@levkk

levkk commented Aug 24, 2026

Copy link
Copy Markdown
Collaborator

Might also want to look at combining it with Route. That thing has a lot of context that you will care about, .e.g., aggregate handling, sorting, limit/offset + routing information. All of this will be needed for the EXPLAIN 2.0.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants