Greedy query planning for large connected components

[joka921]

So far, the query planning took very long when the query graph has a large connected component. With this change, the query planner counts the number of connected subgraphs for each connected component. If that number exceeds a certain budget, the query planning for the component is done using so-called Greedy Operator Ordering (GOO). For a connected component with n nodes, GOO considers a quadratic number of plans, whereas the optimal dynamic programming potentially considers an exponential number of plans. The budget can be controlled via the runtime parameter query-planning-budget (default: 1500).

[sonarcloud]

Quality Gate passed

Issues
7 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarCloud

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 88.33%. Comparing base (fb7b50b) to head (20a5538).
Report is 1 commits behind head on master.

Additional details and impacted files

@@            Coverage Diff             @@
##           master    #1442      +/-   ##
==========================================
+ Coverage   88.27%   88.33%   +0.05%     
==========================================
  Files         361      362       +1     
  Lines       27198    27319     +121     
  Branches     3663     3682      +19     
==========================================
+ Hits        24009    24131     +122     
+ Misses       1954     1952       -2     
- Partials     1235     1236       +1     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[hannahbast]

Had a first look with Johannes. Awesome that this was possible with so little code. Speaks for the quality of the question planner code!

[hannahbast]

Thorough 1-1 with Johannes, during which I made various changes that I will commit next

[hannahbast]

@joka921 Thanks a lot + looks great now. Four more nitpicks:

1. expectDifferentPlanners looks like a misnomer (look at its many applications in test/QueryPlannerTest.cpp). Can you find a better name?
2. How about calling the runtime parameter query-planning-budget (it's not really the budget for greedy query planning, as the current name suggests, but rather a threshold beyond which we switch to greedy query planning). Alternatives would be query-planning-threshold (which sounds a bit generic) or greedy-query-planning-threshold (which is a bit long).
3. Shouldn't we drop the use-greedy-planning parameter now? We can always simulate it by setting the budget to zero or to a very large number
4. Is there a test for the if (graph.size() > 64) { return budget + 1; } case? The comment currently says that we are not sure whether this condition can ever be true.

NOTE: The description of the PR above mentions the runtime parameter. Please make sure that the names are consistent.

[joka921]

@hannahbast

1. The default function (check with both planners) is now again called only expect (reduce the change), The other ones have explicit names that state, that you only want greedy or dynamic programming respectively.
2. I went with query-planning-budget which seems to be consistent with the current commit message.
3. Agreed and dropped
4. I replaced this if by an assertion that explicitly tells us where we have to change things should we ever lift the restriction of 64 elements.

The other suggestions are from Codecov etc.

[hannahbast]

This is now ready to merge (assuming the tests run through)

[sonarcloud]

Quality Gate passed

Issues
2 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarCloud