planner: don't recompute the hashcode when generated column substitution doesn't happen

[AilinKid]

What problem does this PR solve?

Issue Number: close #42788

Problem Summary:

What is changed and how it works?

currently Expression.Hashcode() functionality is only used in some limited comparison cases, so lazy computation is necessary.
Say memory formular for every DNF item is m(?)

OR                 root node                 hashcode mem consumption: 
(a  OR)                                       m(a) + m(child) = m(a) + m(b) + m(c) + ... m(y) + m(z)
  (b  OR)
     (c  OR)
        (d  OR)
           (e  OR)
              (f  OR)                         m(f) + m(child) = m(f) + m(x) + m(y) + m(y)  
                 (x  OR)                      m(x) + m(child) = m(x) + m(y) + m(y)  
                   (y   z)                    m(y);  m(z);      
                                              total: m(a)+m(b)*2+m(c)*3+ ....+m(x)*(n-1)+m(y)*n+m(z)*n, assume the tree depth is n.

from the case above, when computing the hashcode from the raw tree format, additional mem consumption should be allocated since the hashcode cache in every OR Expression except for basic column hashcode comsumption: (m(a) + m(b) + m(c) + ... m(y) + m(z))

additionally, actually we rarely need to compute the hashcode from root node, from the most usage from TiDB expression deduplication cases after flatten DNF expressions, what we only need to do is to output every hashcode for every single flattenDNFItem above, which consuming as just few as (m(a) + m(b) + m(c) + ... m(y) + m(z)) as we said above.

Check List

Tests

• Unit test
• Integration test
• Manual test (add detailed scripts or steps below)
• No code

Side effects

• Performance regression: Consumes more CPU
• Performance regression: Consumes more Memory
• Breaking backward compatibility

Documentation

• Affects user behaviors
• Contains syntax changes
• Contains variable changes
• Contains experimental features
• Changes MySQL compatibility

Release note

Please refer to Release Notes Language Style Guide to write a quality release note.

planner: don't recompute the hashcode when generated column substitution 't happened

[tiprow]

Hi @AilinKid. Thanks for your PR.

PRs from untrusted users cannot be marked as trusted with /ok-to-test in this repo meaning untrusted PR authors can never trigger tests themselves. Collaborators can still trigger tests on the PR using /test all.

I understand the commands that are listed here.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[codecov]

Codecov Report

Merging #46450 (a57b178) into master (66ddb7b) will increase coverage by 0.3405%.
Report is 80 commits behind head on master.
The diff coverage is 87.5000%.

Additional details and impacted files

@@               Coverage Diff                @@
##             master     #46450        +/-   ##
================================================
+ Coverage   73.3963%   73.7368%   +0.3405%     
================================================
  Files          1295       1337        +42     
  Lines        393622     413625     +20003     
================================================
+ Hits         288904     304994     +16090     
- Misses        86337      90214      +3877     
- Partials      18381      18417        +36     

Flag	Coverage Δ
integration	26.8716% <87.5000%> (?)
unit	74.4363% <87.5000%> (+1.0400%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

Components	Coverage Δ
dumpling	54.0444% <ø> (ø)
parser	85.1859% <ø> (+0.1226%)	⬆️
br	49.0707% <ø> (-3.2640%)	⬇️

[AilinKid]

for better performance, we could even just clean the hashcode as [:0] here because the computed hashcode for the toper/topest OR expression is never being used. Let it be computed as lazily as it encounters the needs of the hashcode of flattenDNFItem

[ti-chi-bot]

[LGTM Timeline notifier]

Timeline:

• 2023-08-31 06:18:21.703336169 +0000 UTC m=+1994266.252352151: ☑️ agreed by qw4990.
• 2023-09-01 08:48:12.731060369 +0000 UTC m=+2089657.280076360: ☑️ agreed by winoros.

[fixdb]

+1

[ti-chi-bot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: fixdb, qw4990, winoros

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [qw4990,winoros]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[AilinKid]

/retest

[tiprow]

@AilinKid: Cannot trigger testing until a trusted user reviews the PR and leaves an /ok-to-test message.

In response to this:

/retest

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[AilinKid]

/test unit-test

[tiprow]

@AilinKid: Cannot trigger testing until a trusted user reviews the PR and leaves an /ok-to-test message.

In response to this:

/test unit-test

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[ti-chi-bot]

In response to a cherrypick label: new pull request created to branch release-5.4: #46627.

[ti-chi-bot]

In response to a cherrypick label: new pull request created to branch release-6.1: #46628.

[ti-chi-bot]

In response to a cherrypick label: new pull request created to branch release-6.5: #46629.

[ti-chi-bot]

In response to a cherrypick label: new pull request created to branch release-7.1: #46630.