planner: integrate hashEqual interface into LogicalPlan and expression.Expression.

[AilinKid]

What problem does this PR solve?

Issue Number: ref #51664

Problem Summary:

What changed and how does it work?

in the #55570 we introduced a new kind of HashEqual interface, for simplest hash uint64 digest from some primitive types.

And this kind of interface should be implemented by logicalPlan and expression.Expression to quick hash themselves and to compare the same type structure if they are equivalent.

The first thing came into my mind is that, we should let comprehensive LogicalPlan interface and expression.Expression go include this small trait, why i find it will cause too much change for interface's original implementation. Because it's a generic interface, when it is integrated in: it will make this two to be generic

which will cause all the place that referred to this two big interface to be redefined as xxx[any] as well. it's not that clean work. So we think about a way to define two new interface as:

// LogicalOperator is the interface for logical operators.
// It is used to represent the logical operators in the cascades framework.
// Since the LogicalPlan are the only implementation of normal interface{}
// with generic. Once we introduce a new generic HashEquals[T] inside it,
// like:
//
//	type LogicalPlan interface {
//			Plan
//	 	HashEquals[T]
//	 	...
//	}
//
// it will make the every implementor of LogicalPlan changed a lot. That's
// why this upper kind of LogicalOperator interface is introduced. And it
// will be used in the cascades framework.
//
// With this interface, every original LogicalPlan implementor don't need
// to change any old implementations, only have to add the two functions of
// Hash64 and Equals to become a LogicalOperator.
type LogicalOperator[T any] interface {
	base.LogicalPlan
	HashEquals[T]
}

// ScalarOperator is the interface for scalar operators.
// It is used to represent the scalar operators in the cascades framework.
// It is named for expression.Expression with HashEquals[T] interface. For
// the same reason as above LogicalOperator, we introduce this interface to
// avoid changing the original implementation of expression.Expression.
type ScalarOperator[T any] interface {
	expression.Expression
	HashEquals[T]
}

the logical expression that will be used in memo, we will referred them as LogicalOperator, which kept all the elements that LogicalExpression has while requiring HashEquals implementations on it. With that we don't need to do much change about current implementation function, only adding these two addition functional is enough.

Finally, after discussion, we derive a solution like below, getting rid of generic and use any instead.

// Hash64 is the interface for hashcode.
// It is used to calculate the lossy digest of an object to return uint64
// rather than compacted bytes from cascaded operators bottom-up.
type Hash64 interface {
	// Hash64 returns the uint64 digest of an object.
	Hash64(h Hasher)
}

// Equals is the interface for equality check.
// When we need to compare two objects when countering hash conflicts, we can
// use this interface to check whether they are equal.
type Equals interface {
	// Equals checks whether two base objects are equal.
	Equals(any) bool
}

// HashEquals is the interface for hash64 and equality check.
type HashEquals interface {
	Hash64
	Equals
}

And we did a benchmark for this, the any usage seem adequate: https://github.com/pingcap/tidb/pull/55652/files#diff-ef9b611a397bd5133fb3b00e5fca906beee78179821ee20a308e22110ead85aeR93

Check List

Tests

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

  • I checked and no code files have been changed.

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.

None

[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-sigs/prow repository.

[AilinKid]

just a future example

[elsa0520]

Have you ever implemented the equals function of LogicalSchemaProducer ?

[AilinKid]

currently not, this is is just a example and reminder for next few pull requests.

[codecov]

Codecov Report

Attention: Patch coverage is 0% with 43 lines in your changes missing coverage. Please review.

Project coverage is 74.5166%. Comparing base (ebbe53c) to head (2ac16fd).
Report is 11 commits behind head on master.

Additional details and impacted files

@@               Coverage Diff                @@
##             master     #55652        +/-   ##
================================================
+ Coverage   72.9612%   74.5166%   +1.5554%     
================================================
  Files          1581       1585         +4     
  Lines        442690     444031      +1341     
================================================
+ Hits         322992     330877      +7885     
+ Misses        99873      92859      -7014     
- Partials      19825      20295       +470     

Flag	Coverage Δ
integration	48.9595% <0.0000%> (?)
unit	71.8505% <0.0000%> (-0.1974%)	⬇️

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

Components	Coverage Δ
dumpling	52.9567% <ø> (ø)
parser	∅ <ø> (∅)
br	49.9369% <ø> (+3.9876%)	⬆️

[hawkingrei]

Can we remove it?

[AilinKid]

no, next pull request will introduce hashEqual to expression.Expression, which will enable the comment line here.

[hawkingrei]

OK

[elsa0520]

Maybe we need to remove this bench test

[AilinKid]

make sense, done

[elsa0520]

LGTM

[ti-chi-bot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: elsa0520, hawkingrei

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:

• pkg/planner/OWNERS [elsa0520,hawkingrei]

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:

• 2024-08-27 07:14:24.674067015 +0000 UTC m=+854459.808517135: ☑️ agreed by elsa0520.
• 2024-08-27 07:49:43.023838378 +0000 UTC m=+856578.158288499: ☑️ agreed by hawkingrei.