executor: generate fields in chunkRowRecordSet lazily

[sticnarf]

What problem does this PR solve?

Issue Number: ref #36049

What is changed and how it works?

colNames2ResultFields was always called in runPessimisticSelectForUpdate. But the Fields method of chunkRowRecordSet is not always used. We can set fields to nil first in runPessimisticSelectForUpdate and generate it lazily when Fields is really called.

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

Release note

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

None

[ti-chi-bot]

[REVIEW NOTIFICATION]

This pull request has been approved by:

• cfzjywxk
• ekexium

To complete the pull request process, please ask the reviewers in the list to review by filling /cc @reviewer in the comment.
After your PR has acquired the required number of LGTMs, you can assign this pull request to the committer in the list by filling /assign @committer in the comment to help you merge this pull request.

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

Reviewer can indicate their review by submitting an approval review.
Reviewer can cancel approval by submitting a request changes review.

[ekexium]

LGTM. Is it possible to cache the results for the same inputs?

[sticnarf]

LGTM. Is it possible to cache the results for the same inputs?

Caching is possible. But I find it is not called if the statement has a prepared plan cache. So.. Maybe not quite necessary?

[sre-bot]

Code Coverage Details: https://codecov.io/github/pingcap/tidb/commit/2ea923f26bbebc931d6db9cfec0c7261d8a362ae

[cfzjywxk]

LGTM. Is it possible to cache the results for the same inputs?

Caching is possible. But I find it is not called if the statement has a prepared plan cache. So.. Maybe not quite necessary?

@sticnarf
Do you mean the colNames2ResultFields is not called if the prepared plan cache is used?

[sticnarf]

LGTM. Is it possible to cache the results for the same inputs?

Caching is possible. But I find it is not called if the statement has a prepared plan cache. So.. Maybe not quite necessary?

@sticnarf Do you mean the colNames2ResultFields is not called if the prepared plan cache is used?

Yes. More accurately, the Fields method of the result set is not called if preparedStmt is not nil:

tidb/server/driver_tidb.go

Line 447 in 5a4c14c

if trs.preparedStmt != nil {

Then, colNames2ResultFields is not called because we use the cached columns info.

[cfzjywxk]

/merge

[ti-chi-bot]

This pull request has been accepted and is ready to merge.

Commit hash: 9496f4b

[sre-bot]

TiDB MergeCI notify

CI Name	Result	Duration	Compare with Parent commit
idc-jenkins-ci/integration-cdc-test	🟢 all 36 tests passed	29 min	Existing passed
idc-jenkins-ci-tidb/integration-common-test	🟢 all 17 tests passed	13 min	Existing passed
idc-jenkins-ci-tidb/common-test	🟢 all 11 tests passed	13 min	Existing passed
idc-jenkins-ci-tidb/integration-ddl-test	🟢 all 6 tests passed	6 min 44 sec	Existing passed
idc-jenkins-ci-tidb/tics-test	🟢 all 1 tests passed	5 min 52 sec	Existing passed
idc-jenkins-ci-tidb/sqllogic-test-2	🟢 all 28 tests passed	5 min 46 sec	Existing passed
idc-jenkins-ci-tidb/sqllogic-test-1	🟢 all 26 tests passed	4 min 33 sec	Existing passed
idc-jenkins-ci-tidb/mybatis-test	🟢 all 1 tests passed	3 min 23 sec	Existing passed
idc-jenkins-ci-tidb/integration-compatibility-test	🟢 all 1 tests passed	3 min 14 sec	Existing passed
idc-jenkins-ci-tidb/plugin-test	🟢 build success, plugin test success	4min	Existing passed