[SERVER-30991] Introduce MatchExpression::optimize() Created: 07/Sep/17  Updated: 30/Oct/23  Resolved: 29/Sep/17

Status: Closed
Project: Core Server
Component/s: Querying
Affects Version/s: None
Fix Version/s: 3.6.0-rc0

Type: Task Priority: Major - P3
Reporter: David Storch Assignee: Justin Seyster
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Depends
is depended on by SERVER-30751 Test against optimized match expressi... Closed
Backwards Compatibility: Fully Compatible
Sprint: Query 2017-10-02, Query 2017-10-23
Participants:

 Description   

This would allow arbitrary match expression nodes to optimize themselves, and for such optimizations to roll up through that node's ancestors. It could look similar to the existing Expression::optimize() virtual method.



 Comments   
Comment by Githook User [ 29/Sep/17 ]

Author:

{'email': 'justin.seyster@mongodb.com', 'name': 'Justin Seyster', 'username': 'jseyster'}

Message: Reapply "SERVER-30991 Introduce MatchExpression::optimize()."

This patch undoes the revert in
3cf4e0593c394dd7eb45d8000d76b5dc73a3f425 and includes minor changes to
fix the compiler problem that resulted in the previous revert.
Branch: master
https://github.com/mongodb/mongo/commit/b3bdd98e0d9cab6857590c174a81911a9a8205ac

Comment by Githook User [ 29/Sep/17 ]

Author:

{'email': 'justin.seyster@mongodb.com', 'name': 'Justin Seyster', 'username': 'jseyster'}

Message: Revert "SERVER-30991 Introduce MatchExpression::optimize()."

This reverts commit 3cf4e0593c394dd7eb45d8000d76b5dc73a3f425.

Reverting because of a Clang compile error.
Branch: master
https://github.com/mongodb/mongo/commit/e3bb43cfa8ac0d04ba28ffd3b09a53785feabb31

Comment by Githook User [ 28/Sep/17 ]

Author:

{'email': 'justin.seyster@mongodb.com', 'name': 'Justin Seyster', 'username': 'jseyster'}

Message: SERVER-30991 Introduce MatchExpression::optimize().

This patch refactors CanonicalQuery::normalizeTree() so that the
normalization logic for each type of MatchExpression goes with the
class, rather than all the optimization rules getting bundled into one
huge else if chain.

We wanted something along the lines of an optimize() member function
that would optimize 'this' and return the optimized result (possibly
the same object). However, we also wanted unique_ptr semantics, so
that the optimize function creates a new tree that does not include
the original object, it autmotatically gets destroyed. There's no way
to specify a member function that accepts a unique_ptr 'this' value.

To get around that, we provide a getOptimizer() private function that
returns a function with the unique_ptr signature we want:
unique_ptr<MatchExpression> -> unique_ptr<MatchExpression>.

This way, we still get to replace our if else chain with virtual
dispatch, and we can maintain unique_ptr semantics for the
MatchExpression tree.
Branch: master
https://github.com/mongodb/mongo/commit/3cf4e0593c394dd7eb45d8000d76b5dc73a3f425

Generated at Thu Feb 08 04:25:40 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.