[SERVER-79633] [CQF] Consider the expression child of an EvaluationNode when determining its cost Created: 02/Aug/23  Updated: 14/Aug/23

Status: Backlog
Project: Core Server
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Major - P3
Reporter: Ben Shteinfeld Assignee: Backlog - Query Optimization
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
is related to SERVER-76272 Improve cost model for Filter and Eva... Backlog
is related to SERVER-79635 [CQF] Consider the number of projecti... Closed
Assigned Teams:
Query Optimization
Participants:

 Description   

Currently the cost of EvaluationNode is a function of its child's cardinality estimate, the startup cost + marginal cost coefficients. The number/depth of path elements in the node is not considered.

This led to confusion in the implementation of SERVER-79034, see discussion here, where two alternatives were computed to have identical cost, despite one plan known to be better.

Here are some simplified plan snippets which demonstrate the problem. Both plans generate a projection for "a.b", one doing as an explicit projection while the other pushing the projection of "a" into the PhysicalScan. But both have the same cardinality estimates and the same number of Evaluation nodes, and thus end up with the same cost.

 

Evaluation [{proj_a_b}]
|  EvalPath []
|  |  Variable [root]
|  PathGet [a]
|  PathGet [b]
|  PathIdentity
PhysicalScan [{'<root>': root}]

Evaluation [{proj_a_b}]
| EvalPath []
| | Variable [proj_a]
| PathGet [b]
| PathIdentity
PhysicalScan [{'<root>': root, 'a': proj_a}]

 


Generated at Thu Feb 08 06:41:30 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.