-
Notifications
You must be signed in to change notification settings - Fork 275
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add support for DELETE query planning #538
Add support for DELETE query planning #538
Conversation
a55b0d4
to
a42b185
Compare
3d2ac33
to
57c7a56
Compare
f46fcee
to
e83819e
Compare
core/translate/planner.rs
Outdated
group_by: None, | ||
order_by: None, | ||
aggregates: vec![], | ||
limit: None, // TODO: add support for limit |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This should be fairly simple to add, search for DecrJumpZero
in emitter.rs
and put one of those in emit_delete_insns()
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I want to maintain this PR small for now. And I want to improve my understanding on limit(+ order by).
What do you think of I add a follow up PR right after?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Changed my mind. Added limit support 🤖
@penberg do you have any infinite wisdom about what we should do about this PR? the query planner part for DELETE looks good, but since there is no actual delete implementation, it just prints which rowids it would have deleted. should we merge this behind a default-off feature flag to reduce confusion in case someone actually uses the lib |
@jussisaurio @seonWKim I think we can just merge this (as soon as someone fixes the merge conflicts). We can hide it under a general-purpose feature flag like "experimental" or "preview" but I don't think that's necessarily needed right now. We're at 0.0.10 so hopefully people understand that many things just don't work. |
@penberg I'll resolve the conflict and let you know |
Purpose of this PR
Support for DELETE query execution planning
Implementation Details
The main entry point for planning DELETE queries is the
translate_delete
function. It is composed of three primary steps:prepare_delete_plan
:optimize_delete_plan
:emit_program_for_delete
:I've tried to reuse existing logic(mostly on SELECT operations) as much as I can, so that we can automatically incorporate new changes automatically.
Delete planning debug
I've used
println!(...)
to specify the rows to delete. Example belowBytecode compatibility
EXPLAIN DELETE FROM users WHERE id = 1;
EXPLAIN DELETE FROM users WHERE id > 3
EXPLAIN DELETE FROM users WHERE id < 3
TODO(future works)
Clear
opcodedelete
is implemented inCursor