Skip to content
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

Figure out transformation and implementation rule APIs #17

Open
connortsui20 opened this issue Jan 29, 2025 · 1 comment
Open

Figure out transformation and implementation rule APIs #17

connortsui20 opened this issue Jan 29, 2025 · 1 comment

Comments

@connortsui20
Copy link
Member

The implementation rule API is likely pretty simple, so we should aim to stabilize that quickly.

On the other hand, we should make sure the transformation rule API makes sense. Returning a Vec<LogicalExpression> doesn't really make sense because transformation rules really emit a whole bunch of things including logical expressions, groups, and scalars.

However, we also don't want to just return a single PartialLogicalPlan since that loses a lot of information that the rule might know (for example, the rule should know what expressions are potentially new vs the ones that are old).

@connortsui20 connortsui20 mentioned this issue Jan 29, 2025
@yliang412
Copy link
Member

If we can correctly handle the following example, I think we are good to go:

Example:

Filter push down predicates down below a Join:

Initial Plan:

(r) Filter            // group 10, scalar annotation: t2.v1 > 10 
    (s) Greater       // group 9
        (s) t1.v1     // group 8
        (s) 10        // group 7 
    (r) Join          // group 6, scalar annotation: t1.v1 = t2.v1
        (s) Eq        // group 5
            (s) t1.v1 // group 4
            (s) t2.v1 // group 3
        (r) Scan (t1) // group 1
        (r) Scan (t2) // group 2

match / "check_pattern":

(r) Filter            // group 10, scalar annotation: t2.v1 > 10 
    (s) Greater       // group 9
        (s) t1.v1     // group 8
        (s) 10        // group 7 
    (r) Join          // group 6, scalar annotation: t1.v1 = t2.v1
        (s) Eq        // group 5
            (s) t1.v1 // group 4
            (s) t2.v1 // group 3
        (r) GroupId(1)
        (r) GroupId(2)

After the apply:

(r) Join // NEW EXPR, OLD GROUP
   (s) Eq        // group 5, OLD
       (s) t1.v1 // group 4, OLD
       (s) t2.v1 // group 3, OLD
   (r) GroupId(1) // OLD
   (r) Filter // NEW EXPR, NEW GROUP
        (s) Greater       // group 9
            (s) t1.v1     // group 8
            (s) 10        // group 7 

If we return a partial plan, then we will have the information of which group (r) Filter // NEW EXPR, NEW GROUP belongs to before inserting the Join // NEW EXPR, OLD GROUP.

There might be a more clever way to deal with this.

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

No branches or pull requests

2 participants