Encapsulate time range constraints for predicate pushdown

[tlento]

MetricFlow currently allows for a limited scope form of filter
predicate pushdown that is particular to time range constraints where
the querying user has provided an explicit time window for us to
query against. The application of the pushdown operation is managed
by threading the time range constraint through the entire dataflow
plan builder and applying the filter operation as appropriate.

This is exactly what we need to do for robust predicate pushdown
evaluation for our expanded set of pushdown operations. Rather than
wire a whole new set of parameters through, we simply encapsulate
the time range constraints inside of a new object that is more
readily extensible to other predicate pushdown handling.

This specific change is as mechanical as possible in order to minimize
confusion. Places that stood out for improvement via the encapsulating
object have been marked for later updates, which will follow shortly.

[tlento]

• Use pushdown params to disable time range constraint pushdown #1216 : 2 dependent PRs (#1217 , #1218 )
• Encapsulate time range constraints for predicate pushdown #1215 👈
• Add conversion metric rendering tests #1214
• main

This stack of pull requests is managed by Graphite. Learn more about stacking.

Join @tlento and the rest of your teammates on Graphite

[github-actions]

Thank you for your pull request! We could not find a changelog entry for this change. For details on how to document a change, see the contributing guide.

[plypaul]

Nit: The issue that I've run into with classes that are plural is that when you have a variable that is a collection of them, it's unclear how to name the variable. I've been using ...ParameterSet instead, but up for other ideas.

[tlento]

Oh yeah, good point. I don't think we'd ever want to collect these but also I never like having the name parameters in a class. It's not utils-level bad but it still basically means "bag of crap."

Maybe PredicatePushdownState? It effectively tracks the known predicates and whether or not to attempt to push them down, so at any point you have a representation of state you can use to apply a constraint (or not).

[tlento]

Oops I already use PredicatePushdownState as a state enumeration later on. 🤦

PredicatePushdownDirective? PredicatePushdownEvaluationInput? ThingsWeNeedToDoPredicatePushdownCorrectly?

I'm going with directive because it's least verbose. We can rename later if we need to.

[tlento]

@plypaul PredicatePushdownState is now available! Renamed in #1224 - tried to do it here but it was a huge pain.

[tlento]

Merge activity

• May 23, 5:33 PM PDT: @tlento started a stack merge that includes this pull request via Graphite.
• May 23, 5:34 PM PDT: Graphite rebased this pull request as part of a merge.
• May 23, 5:40 PM PDT: @tlento merged this pull request with Graphite.