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

Query planner passes #588

Merged
merged 7 commits into from
May 19, 2022

Conversation

dlurton
Copy link
Member

@dlurton dlurton commented Apr 29, 2022

Originally part of #582, this commit is based on #587, which must be merged first. However, it may be helpful to review the PR introducing the PlannerPipeline first (#590), if more context for these changes is desired.

This PR contains 3 query planner passes:

  • Convert AST to logical plan
  • Logical plan -> Resolved logical plan. This pass assigns indexes to all local variables, and resolves references to global variables. (undefined variables are detected and reported here).
  • Resolved logical plan -> physical plan

These are not yet integrated with anything--that's in #590.

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

Base automatically changed from physical-plan-staging-thunk to physical-plan-staging May 10, 2022 22:26
- AST->logical
- logical->resolved
- lesolved->physical.

Not yet integrated with anything--that will come in a future commit.
@dlurton dlurton force-pushed the physical-plan-staging-planner-passes branch from ac6155a to 48a003e Compare May 10, 2022 23:03
@dlurton dlurton requested review from alancai98, lziq and am357 and removed request for alancai98 May 11, 2022 16:18
Copy link
Contributor

@lziq lziq left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just finished review for AstToLogicalVisitorTransform.kt and related test files. Generally, it looks good to me. Will continue to review rest of the changes.

Copy link
Contributor

@am357 am357 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Had a review and left some comments w/ requesting code changes if they make sense.

Comment on lines +26 to +29
// Workaround for a bug in PIG that is fixed in its next release:
// https://github.com/partiql/partiql-ir-generator/issues/41
fun List<IonElement>.asAnyElement() =
this.map { it.asAnyElement() }
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

While at it, shouldn't we just release the PIG and remove this?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, but partiql/partiql-ir-generator#41 hasn't been fixed yet.

import org.partiql.lang.eval.BindingCase
import org.partiql.lang.eval.BindingName

/** Indicates the result of an attempt to resolve a global binding. */
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I understand we have kdoc for GlobalBindings.resolve() but can we also add a definition for Global Binding here?

BTW.
I think it's helpful to have the link to the upcoming documentation in applicable constructs under planner.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I have rephrased this to be more clear.

Comment on lines 14 to 19
/**
* A success case, indicates the [index] of the only possible match to the [BindingName] in a local lexical scope.
* This is `internal` because [index] is an implementation detail that shouldn't be accessible outside of this
* library.
*/
internal data class LocalVariable(val index: Int) : ResolutionResult()
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Considering that GlobalBindings.resolve() is meant to return GlobalVariable or undefined, should this be here?

Copy link
Member Author

@dlurton dlurton May 13, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's internal, so it's not exposed to customers. Customer code is never intended to resolve local variables, so this fits the situation. Having this here does simplify a few things in relation in the LogicalToLogicalResolvedVisitorTransform class. Namely, I found this to be preferable to having two variations of this sealed class: one that is public and only has GlobalVariable and Undefined, and another that is private and has GlobalVariable, Undefined as well as LocalVariable. There would also need to be logic to convert from the public variation to the private.

Making one member of a public sealed class internal is perhaps a little unusual, but unusual doesn't equate to undesirable, necessarily. Was there a specific concern you had with this approach?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I wasn't worried about exposing it, I just thought this data class doesn't belong here. I think your explanation makes sense, so let's leave it as is.

data class Success<TResult>(val result: TResult, val warnings: List<Problem>) : PassResult<TResult>()

/**
* Indicates query planning was not successful and includes a list of errors and warnings that were encountered
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

errors and warnings -> errors?

Copy link
Member Author

@dlurton dlurton May 13, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is designed to allow us to continue at least the current pass in the event of a semantic error instead of throwing an exception. That means its entirely possible to encounter both warnings and errors. I'll add a note.

* we keep going to provide the end user any additional error messaging, unless [ProblemHandler.handleProblem] throws
* an exception when an error is logged. **If any undefined variables are detected, in order to allow traversal to
* continue, a fake index value is used in place of a real one and the resolved logical plan returned by this function
* is guaranteed to be invalid.** **Therefore, it is the responsibility therefore of callers to check if any problems
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A redundant _therefore`?

Copy link
Member Author

@dlurton dlurton May 13, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Out of order, actually. Fixing... EDIT: nope, redundant. Removing.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

also added a couple dozen lines about $__dynamic_lookup__

/**
* This is the version number of the logical and physical plans supported by this version of PartiQL.
*
* It would be nice to embed this in the PIG domain somehow, but this isn't supported, so we have to include it
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Didn't we introduce the version number in the new domains. I'm sure you feel the same way, but this is not great. Even if going with this hard-coding, the version doesn't tell anything about backward compatibility; shouldn't we adopt a format like SemVer?

Copy link
Member Author

@dlurton dlurton May 13, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I really think this aught to be something solved by PIG actually so I created partiql/partiql-ir-generator#121

I would like to leave this as-is for now if you don't mind.

Copy link
Member Author

@dlurton dlurton May 16, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'll add a link to the ticket in the comment.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do you also mind adding some comments to

            (record plan
                (stmt statement)
                (version int)
            )

in the partiql.ion file, to state that the version number here will be removed and assigned to PIG domains once partiql/partiql-ir-generator#121 is resolved?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would like to leave this as-is for now if you don't mind.

I think this is something that we need to fix before we expose the API; once we have the version as is and the API is exposed, then it's too late. Happy to discuss further offline.

Copy link
Member Author

@dlurton dlurton May 17, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Offline discussion indicates this doesn't need to be addressed in this PR, but should be addressed before this hits main. Creating an issue in the related milestone to track this: #605

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just an update on this; as a comprise, requested having the version as SemVer hard-coded for now. @dlurton had a point on using patch—which is for bug fixes—might not be applicable to our use-case. We ultimately agreed on having major and minor notions in the version for now.

return planWithAllocatedVariables to allLocals.toList()
}

private const val VARIABLE_ID_META_TAG = "\$variable_id"
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nit.: I'm thinking if we need to get all the constants in one place under planner.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In general, I'd rather not have one file with a bunch of unrelated constants. Note that this is private, putting it somewhere else means it can't be private anymore and will pollute the package namespace. Putting the constant here also has the advantage that the definition is close to its uses, which improves readability IMHO.

@dlurton dlurton requested review from am357 and lziq May 16, 2022 20:58
Copy link
Contributor

@lziq lziq left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just finished the review. Overall it looks good to me.

/**
* This is the version number of the logical and physical plans supported by this version of PartiQL.
*
* It would be nice to embed this in the PIG domain somehow, but this isn't supported, so we have to include it
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do you also mind adding some comments to

            (record plan
                (stmt statement)
                (version int)
            )

in the partiql.ion file, to state that the version number here will be removed and assigned to PIG domains once partiql/partiql-ir-generator#121 is resolved?

@lziq
Copy link
Contributor

lziq commented May 19, 2022

The new commit makes sense to me and there is no more file change requested from my side. If @am357 also agrees, I think we can merge this PR.

@dlurton dlurton merged commit 77b522b into physical-plan-staging May 19, 2022
@dlurton dlurton deleted the physical-plan-staging-planner-passes branch May 19, 2022 20:51
dlurton added a commit that referenced this pull request May 27, 2022
Merges the following PRs to `main`:

- #583 
- #584 
- #587 
- #588 
- #589 
- #609 
- #590 
- #592 

Also, this adds a TODO comment (ea40e4a, requested by @am357 in offline chat) and excludes `PlannerPipeline` from the new aggregate tests which were pulled in when merging from `main` and were not part of the other PRs (34025b3).

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
RCHowell pushed a commit that referenced this pull request Jun 1, 2022
Merges the following PRs to `main`:

- #583 
- #584 
- #587 
- #588 
- #589 
- #609 
- #590 
- #592 

Also, this adds a TODO comment (ea40e4a, requested by @am357 in offline chat) and excludes `PlannerPipeline` from the new aggregate tests which were pulled in when merging from `main` and were not part of the other PRs (34025b3).

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
RCHowell pushed a commit that referenced this pull request Jun 1, 2022
Merges the following PRs to `main`:

- #583 
- #584 
- #587 
- #588 
- #589 
- #609 
- #590 
- #592 

Also, this adds a TODO comment (ea40e4a, requested by @am357 in offline chat) and excludes `PlannerPipeline` from the new aggregate tests which were pulled in when merging from `main` and were not part of the other PRs (34025b3).

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
RCHowell pushed a commit that referenced this pull request Jun 1, 2022
Merges the following PRs to `main`:

- #583 
- #584 
- #587 
- #588 
- #589 
- #609 
- #590 
- #592 

Also, this adds a TODO comment (ea40e4a, requested by @am357 in offline chat) and excludes `PlannerPipeline` from the new aggregate tests which were pulled in when merging from `main` and were not part of the other PRs (34025b3).

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
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.

3 participants