[Tech Request]: time and datetime type can not fold correctly (#14698)

[badboynt1]

constand fold time and datetime type, and calculate stats correctly

Approved by: @aunjgr

What type of PR is this?

• API-change
• BUG
• Improvement
• Documentation
• Feature
• Test and CI
• Code Refactoring

Which issue(s) this PR fixes:

issue #https://github.com/matrixorigin/MO-Cloud/issues/2959

What this PR does / why we need it:

constand fold time and datetime type, and calculate stats correctly

[matrix-meow]

@badboynt1 Thanks for your contributions!

Pull Request Review:

Title:

The title of the pull request is clear and informative, indicating that there is an issue with the folding of time and datetime types.

Body:

The body of the pull request provides a brief description of the changes made in the PR, mentioning constant folding of time and datetime types and ensuring correct calculation of stats. It also references the related issue and the approval status.

Changes:

1. constant_fold.go:

   • In the GetConstantValue function, the conditions for types.T_time and types.T_datetime have been removed. This change might lead to unexpected behavior if the transAll condition was originally intended to prevent certain operations.
   • It seems like the removal of the conditions might have been unintentional. It's important to verify if these conditions were necessary for the correct functioning of the code.
   • If the conditions were removed intentionally, it would be beneficial to add comments explaining the reasoning behind this change for better code readability.

2. stats.go:

   • Additional cases for types.T_time and types.T_datetime have been added to update the MinValMap and MaxValMap. This change seems appropriate for handling time and datetime types correctly.
   • However, it's crucial to ensure that the decoding and handling of time and datetime values are accurate to prevent any data inconsistencies or errors.

3. stats.go:

   • In the calcSelectivityByMinMax function, a default case has been added to set ret to 0.3 if the funcName does not match any existing cases. This default value might not be appropriate and could lead to unexpected behavior.
   • It would be better to handle unknown cases more explicitly, such as logging a warning or throwing an error, rather than assigning a default value that may not be suitable for all scenarios.
   • The additional checks to ensure ret is within the range of 0 to 1 are good practices to prevent invalid selectivity values. However, the comment return -1 // never reach here is misleading and should be removed to avoid confusion.

Suggestions for Improvement:

1. Revisit Condition Removal:

   • Review the removal of conditions in constant_fold.go to ensure it aligns with the intended logic. If the conditions were necessary, consider reintroducing them or adding comments to explain the rationale behind their removal.

2. Verify Time and Datetime Handling:

   • Double-check the decoding and handling of time and datetime values in stats.go to guarantee accuracy and consistency in the calculations.

3. Handle Unknown Cases:

   • Instead of assigning a default value in calcSelectivityByMinMax, consider handling unknown cases explicitly to maintain code clarity and prevent unintended consequences.

4. Remove Misleading Comment:

   • Remove the misleading comment return -1 // never reach here in calcSelectivityByMinMax to avoid confusion and ensure code readability.

By addressing these points, the pull request can be improved in terms of correctness, maintainability, and clarity. It's essential to thoroughly test the changes to ensure they function as expected and do not introduce any regressions or security vulnerabilities.