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

Represent zero-column relations (aka booleans) in the PartialTrieScan interface? #446

Open
matzemathics opened this issue Dec 11, 2023 · 0 comments
Labels
help wanted Extra attention is needed physical physical layer planning engine question Further information is requested technical-debt Refactoring for an implementation that was good enough at the time
Milestone

Comments

@matzemathics
Copy link
Collaborator

matzemathics commented Dec 11, 2023

A relation with zero columns can have two possible values: either the empty set {} or the set containing the empty tuple {()}. Currently there is no way to cleanly represent such a relation in the PartialTrieScan interface. We need this, if we want to generate execution plans, that have "zero column" intermediary results, which is needed if we want to generate one overall execution plan for each rule.

Are there other solutions?

If we change the execution planning engine in such a way, that a single rule can produce multiple execution plans, we could circumvent representing these types of relations in the PartialTrieScan interface. The implementation of this may be simpler, since it does not require the physical layer to change, however it has the downside that optimization of execution plans might become more difficult, and the overall complexity of the planning engine (which is already hard to understand) increases.

Where do we need this?

For fixing the open issues #434, #428, #193

@mmarx mmarx added this to the Release 0.5.0 milestone Dec 11, 2023
@matzemathics matzemathics added help wanted Extra attention is needed question Further information is requested technical-debt Refactoring for an implementation that was good enough at the time labels Dec 11, 2023
@mmarx mmarx added physical physical layer planning engine help wanted Extra attention is needed technical-debt Refactoring for an implementation that was good enough at the time and removed help wanted Extra attention is needed technical-debt Refactoring for an implementation that was good enough at the time labels Dec 11, 2023
@mmarx mmarx modified the milestones: Release 0.5.0, Release 0.6.0 Apr 3, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
help wanted Extra attention is needed physical physical layer planning engine question Further information is requested technical-debt Refactoring for an implementation that was good enough at the time
Projects
Status: Todo
Development

No branches or pull requests

2 participants