Skip to content

search: factor out logic for job optimization

Warren Gifford requested to merge backend-integration/rvt/factor-out-opt-logic into main

Created by: rvantonder

I'm expanding the GQL endpoint to return representations of a query. I want it to return:

  • parse tree
  • unoptimized (generic) job tree
  • optimized job tree

It will make debugging and introspection easier, especially for optimizations--these are going to come up more often for commits, or-expressions over regexp/repos, etc.

Problem is, current job logic for optimization makes it difficult to get an unoptimized representation, because there's no control over whether we run that pass. This PR factors out optimization to be a function that gets passed in (and which can be the identity function) so it's easy to get an unoptimized tree.

This has a nice side effect, where it's easier to test the end-to-end optimized vs unoptimized representation over the entire plan (previously, I just hooked into the basic-query optimization).

See more inline comments.

Test plan

Semantics-preserving, updated tests.

Merge request reports