[SERVER-84366] Incorrect selectivity in explain for complex physical plans Created: 21/Dec/23  Updated: 22/Dec/23

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

Type: Task Priority: Major - P3
Reporter: Timour Katchaounov 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-83441 Pushdown top-level fields from Filter... Closed
is related to SERVER-83456 Skip Filter->Sargable rewrite for col... Closed
Assigned Teams:
Query Optimization
Participants:

 Description   

The implementation of SERVER-83441 introduces a new way to construct a physical plan from a FilterNode when the FilterNode is directly on top of a ScanNode. In this case, similar to the approach in the implementer for SargableNode, the FilterNode implementer creates a complex physical plan consisting directly of a FilterNode on top of a PhysicalScanNode.

The selectivities of both physical nodes computed during their creation are correct, however the infrastructure in the optimizer that is supposed to pass this information to explain is not designed to do this correctly. The result is that explain shows the same CE for the PhysicalScanNode as the one of the FilterNode. Apparently explain picks the selectivity for the whole group instead of the specific per-node selectivity.

As david.percy@mongodb.com said:

it seems like there isn’t a quick fix for this.  It’s a bug in these interfaces: * NodeToGroupPropsMap is a confusing mixture of properties used for different purposes

  • explain wants to show per-physical-node properties
  • takes “group props” and displays it per-node: very misleading
  • plan extraction does not return per-node properties
  • the memo only record properties at group boundaries
  • implementers only return properties at group boundaries

I think the solution is to change explain to only print properties at a group boundary.  And that seems unrelated to your work avoiding Sargable node.

 
There are at least two possible approaches: * Extend/improve the optimizer logic around how node properties are propagated to explan, and make explain pick the correct properties of each node.

  • Impose a limitation that physical rewrites can only produce one physical node per logical node, and reimplement SERVER-83441. This looks very limiting, and is less desirable.

 


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