Support constraints in physical query planning #53
Conversation
gokselk
changed the title
gokselk
force-pushed
the
feature/physical-planner-functional-dependence
branch
from
9f3b41c to
a680f87
Compare
gokselk
force-pushed
the
feature/physical-planner-functional-dependence
branch
2 times, most recently
from
42201f0 to
319f13f
Compare
gokselk
changed the title
gokselk
force-pushed
the
feature/physical-planner-functional-dependence
branch
from
319f13f to
82361a7
Compare
| @@ -254,10 +266,27 @@ impl FileScanConfig { | |||
| self.file_schema.metadata().clone(), | |||
| )); | |||
|
|
|||
| let proj_indices = match &self.projection { | |||
| Some(proj) => proj.to_vec(), | |||
| None => (0..(self.file_schema.fields().len() | |||
There was a problem hiding this comment.
This check match &self.projection has been done above, And also another similar check if self.projection.is_none() exists. Perhaps we can refactor this function, starting with a match pattern on self.projection, wdyt?
There was a problem hiding this comment.
Took a different approach, deduplicated the code in 46b860f. Please let me know if this works as well.
gokselk
force-pushed
the
feature/physical-planner-functional-dependence
branch
from
940c330 to
05384e1
Compare
…anner-functional-dependence
| @@ -548,6 +570,72 @@ impl EquivalenceProperties { | |||
| true | |||
| } | |||
|
|
|||
| /// Checks if the sort requirements are satisfied by any of the table constraints (primary key or unique). | |||
| /// Returns true if any constraint fully satisfies the requirements. | |||
| fn satisfied_by_constraints( | |||
There was a problem hiding this comment.
I am not entirely clear if this check is sufficient to cover all cases. Does this logic address all cases including when a composite key is not contiguous in orderings (i.e. the composite key is (A, B) and ordering is (A, C, B))?
There was a problem hiding this comment.
Do you mean unique columns: [A,B]
Output ordering: [A,C,B]
and required ordering is: [A,C,B,D] or [A,B,D] etc.
I will think on these now
There was a problem hiding this comment.
I've changed the logic in cc3ca91. New one works like this:
- First checks if the constraint indices can form a valid prefix (by length)
- Then finds all orderings that contain the required constraint columns in any position
- For unique constraints, additionally verifies that columns at the start/end are not nullable
- Finally checks if any of these candidate orderings match the required sort prefix exactly
Co-authored-by: Mehmet Ozan Kabak <[email protected]>
…ation object" This reverts commit bbe35d4.
Co-authored-by: Mehmet Ozan Kabak <[email protected]>
gokselk
force-pushed
the
feature/physical-planner-functional-dependence
branch
from
a6c83a7 to
726737b
Compare
|
Merged upstream. |
Which issue does this PR close?
Closes #.
Rationale for this change
What changes are included in this PR?
Are these changes tested?
Are there any user-facing changes?