Add materialized view query optimization utility

[jzzhaofb-zz]

Adding materialized view optimizer utility to optimize eligible queries if supported by a materialized view. The utility is also responsible for validating the original query against the supported formats.

Currently, this utility is very restrictive and supports some simple query formats. It does not support complex queries (Join, Union, subquery, etc.).

== NO RELEASE NOTE ==

[jainxrohit]

Implementing a mechanism which rewrites a base query given a materialized view. Currently it supports simple rewrite (With Alias, Function Call, Where clause, Order by, Having). It does not support join and sub queries.

Test plan: Added unit tests in TestMaterializedViewQueryOptimizer

== NO RELEASE NOTE ==

@jzzhaofb the release note needs to have triple ` at the start and end.

== NO RELEASE NOTE ==

[jainxrohit]

.

[jainxrohit]

Overall in pretty good shape. Good work!

[gggrace14]

I still can't quickly get what types of base query cannot be optimized. Can you add the invalid base query types to TestMaterializedViewQueryOptimizer? A complete unit test suite should include invalid test cases.

[jainxrohit]

I still can't quickly get what types of base query cannot be optimized. Can you add the invalid base query types to TestMaterializedViewQueryOptimizer? A complete unit test suite should include invalid test cases.

@gggrace14 Julian and I discussed about it, the idea for this class is not to cover all non supported cases. We will add MV query validation logic in the candidate extractor. At that time we will add extended set of tests for not supported cases.
The purpose of this class to do basic handling, so that if it reaches in unfamiliar territory, it can fall back on the original query.

[jainxrohit]

one nit requested.

Awesome work!

[highker]

Adding @yuanzhanhku to the review as he has a lot of insight how to check if a MV query is a proper subquery of a select query

[highker]

we need to properly check a scan-filter-project-agg query containment problem. To decide if we can replace a subquery in the given provided select query, we will need to at least satisfy the following conditions:

• the provided select query contains all the columns from the columns selected by the MV
• the provided select query's filter f1 is more restrictive than the one (f2) in the MV. Meaning that f1 implies f2 (https://mathworld.wolfram.com/Implies.html)
• the project has logically equivalent signatures. For example a * b = b * a
• the agg functions should match exactly. However, there could be cases where avg = sum/count; this means if a select query contains avg and MV contains sum and count, it is possible to recover avg from it. We probably can ignore this case at the moment.

[jainxrohit]

The PR has lots of comments, lets clean those and keep the relevant ones only.

[jainxrohit]

few minor changes requested.

[jainxrohit]

@jzzhaofb Lets change the commit and PR to following

Title: Add materialized view query optimization utility

Adding materialized view optimizer utility to optimize eligible queries if supported by a materialized view. The utility is also responsible for validating the original query against the supported formats.

Currently, this utility is very restrictive and supports some simple query formats. It does not support complex queries (Join, Union, subquery, etc.).

[jainxrohit]

LGTM

@highker please have a look.

[highker]

mostly nits