Track prunability of inner joins on the expression itself #32674
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
When a join is added to a select, it's optionally marked as removable, i.e. eligible for pruning if not referenced by any column; this is checked while pruning to prevent removing joins which are important for preserving correct data even when not referenced (e.g. an inner join can be used to filter).
In line with the current architecture, this information is stored on a private list on SelectExpression; this means that all code that accesses it must be on SelectExpression itself (and not on an external visitor, where it can be overridden e.g. by a provider); it also means we must take care to always copy it when duplicating selects, and generally causes unnecessary bookkeeping.
This PR is a pure refactor which moves the information to the tables themselves, where it can be accessed freely from anywhere. This is part of a larger effort to remove private state from SelectExpression and simplify the pipeline.
Part of #31049