planner: don't recompute the hashcode when generated column substitution doesn't happen (#46450)

[ti-chi-bot]

This is an automated cherry-pick of #46450

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

[ti-chi-bot]

This cherry pick PR is for a release branch and has not yet been approved by release team.
Adding the do-not-merge/cherry-pick-not-approved label.

To merge this cherry pick, it must first be approved by the collaborators.

AFTER it has been approved by collaborators, please ping the release team in a comment to request a cherry pick review.

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]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: AilinKid, qw4990

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 [AilinKid,qw4990]

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

[ti-chi-bot]

[LGTM Timeline notifier]

Timeline:

• 2023-10-30 08:37:54.885697274 +0000 UTC m=+2855872.472807416: ☑️ agreed by AilinKid.
• 2023-10-30 09:14:41.108225277 +0000 UTC m=+2858078.695335407: ☑️ agreed by qw4990.