planner: fix a bug when pushing streamAgg down (#41056) by ti-chi-bot · Pull Request #41311 · pingcap/tidb

ti-chi-bot · 2023-02-12T04:00:41Z

This is an automated cherry-pick of #41056

What problem does this PR solve?

Issue Number: close #40857

Problem Summary:
minimal reproduce process:

CREATE TABLE t (
  c1 mediumint(9) DEFAULT '-4747160',
  c2 year(4) NOT NULL DEFAULT '2075',
  c3 double DEFAULT '1.1559030660251948',
  c4 enum('wbv4','eli','d8ym','m3gsx','lz7td','o','d1k7l','y1x','xcxq','bj','n7') DEFAULT 'xcxq',
  c5 int(11) DEFAULT '255080866',
  c6 tinyint(1) DEFAULT '1',
  PRIMARY KEY (c2),
  KEY `c4d86d54-091c-4307-957b-b164c9652b7f` (c6,c4)
);

insert into t values (-4747160, 2075, 722.5719203870632, 'xcxq', 1576824797, 1);

select   /*+ stream_agg() */  bit_or( t.c5 ) as r0 from t 
where t.c3 in ( select c6 from t where not( t.c6 <> 1 ) and not( t.c3 in ( 9263.749352636818 ) ) ) 
group by t.c1;

The following plan will introduce this panic:

mysql> explain select   /*+ stream_agg() */  bit_or( t.c5 ) as r0 from t  where t.c3 in ( select c6 from t where not( t.c6 <> 1 ) and not( t.c3 in ( 9263.749352636818 ) ) )  group by t.c1;
+--------------------------------------------+----------+-----------+-------------------------------------------------------------+----------------------------------------------------------+
| id                                         | estRows  | task      | access object                                               | operator info                                            |
+--------------------------------------------+----------+-----------+-------------------------------------------------------------+----------------------------------------------------------+
| StreamAgg_17                               | 6.66     | root      |                                                             | group by:test.t.c1, funcs:bit_or(test.t.c5)->Column#13   |
| └─Sort_52                                  | 6.66     | root      |                                                             | test.t.c1                                                |
|   └─HashJoin_21                            | 6.66     | root      |                                                             | inner join, equal:[eq(Column#14, test.t.c3)]             |
|     ├─Projection_22(Build)                 | 5.33     | root      |                                                             | cast(test.t.c6, double BINARY)->Column#14                |
|     │ └─StreamAgg_43                       | 5.33     | root      |                                                             | group by:test.t.c6, funcs:firstrow(test.t.c6)->test.t.c6 |
|     │   └─IndexLookUp_44                   | 5.33     | root      |                                                             |                                                          |
|     │     ├─IndexRangeScan_40(Build)       | 10.00    | cop[tikv] | table:t, index:c4d86d54-091c-4307-957b-b164c9652b7f(c6, c4) | range:[1,1], keep order:true, stats:pseudo               |
|     │     └─StreamAgg_29(Probe)            | 5.33     | cop[tikv] |                                                             | group by:test.t.c6,                                      |
|     │       └─Selection_42                 | 6.66     | cop[tikv] |                                                             | ne(test.t.c3, 9263.749352636818)                         |
|     │         └─TableRowIDScan_41          | 10.00    | cop[tikv] | table:t                                                     | keep order:false, stats:pseudo                           |
|     └─TableReader_51(Probe)                | 10000.00 | root      |                                                             | data:TableFullScan_50                                    |
|       └─TableFullScan_50                   | 10000.00 | cop[tikv] | table:t                                                     | keep order:false, stats:pseudo                           |
+--------------------------------------------+----------+-----------+-------------------------------------------------------------+----------------------------------------------------------+
12 rows in set (0.00 sec)

What happend:
In indexLookUp, the handles(row id) fetched from index is originally ordered by index, when keepOrder is true, we will save the order of handles in indexOrder, and then tableWorker will use handles to rescan table to obtain rows. If keepOrder is true, the tableWorker will restore the rows to the original order through indexOrder. When restoring, we need to extract the handle from the row. In the above plan, the agg is pushed down, and its schma only contains c6 and does not contain the handle , but the executor thinks that the handle is in the third column of the row, resulting in "index out of range [2]".

What is changed and how it works?

The reason for the above error is that streamAgg was pushed down to double read when keepOrder was true. I looked through the historical PRs and found that @winoros solved this problem in PR#12443: if the original order of index needs to be maintained during double read (Call this situation doubleReadWithOrderReserved), we will prevent the optimizer from pushing streamagg down to double read. PR#12443 uses extraHandleCol to determine whether the current situation is doubleReadWithOrderReserved. At that time, if extraHandleCol != nil, then it must be the case of doubleReadWithOrderReserved.

But then PR#18054 added !ds.tableInfo.IsCommonHandle, which caused extraHandleCol may be nil in the case of doubleReadWithOrderReserved, so we can’t use extraHandleCol, we can use (cop.indexPlan != nil && cop.tablePlan != nil && cop.keepOrder) to represent this situation .

PR#18054:
- if cop.tablePlan != nil {
+ if cop.tablePlan != nil && !ds.tableInfo.IsCommonHandle {
  	col, isNew := cop.tablePlan.(*PhysicalTableScan).appendExtraHandleCol(ds)
  	cop.extraHandleCol = col
  	// ...
  }

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

Release note

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

None

Signed-off-by: ti-chi-bot <ti-community-prow-bot@tidb.io>

ti-chi-bot · 2023-02-12T04:00:44Z

[REVIEW NOTIFICATION]

This pull request has been approved by:

fixdb

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.

Details

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

fixdb · 2023-02-12T07:14:07Z

@Dousir9 There is merge conflict, can you resolve the conflict? thanks.

Dousir9 · 2023-02-13T03:32:24Z

@Dousir9 There is merge conflict, can you resolve the conflict? thanks.

Sure.

Dousir9 · 2023-02-13T03:41:24Z

/cherry-pick-invite

ti-chi-bot · 2023-02-13T03:41:32Z

@Dousir9 you're not a member of org pingcap

hawkingrei · 2023-02-13T05:12:36Z

/cherry-pick-invite

ti-chi-bot · 2023-02-13T05:12:38Z

@hawkingrei Please accept the invitation then you can push to the cherry-pick pull requests.
Comment with "/cherry-pick-invite" if the invitation is expired.
https://github.com/ti-chi-bot/tidb/invitations

Signed-off-by: Weizhen Wang <wangweizhen@pingcap.com>

Dousir9 · 2023-02-15T06:06:16Z

/retest

Dousir9 · 2023-02-15T07:22:03Z

Thanks for @hawkingrei .

Dousir9 · 2023-02-15T07:22:15Z

/cc fixdb

fixdb

+1

YangKeao

LGTM

ti-chi-bot · 2023-06-30T03:04:14Z

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: fixdb, hawkingrei, YangKeao

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

The pull request process is described here

Details

Needs approval from an approver in each of these files:

~~OWNERS~~ [YangKeao,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 · 2023-06-30T03:04:18Z

[LGTM Timeline notifier]

Timeline:

2023-06-29 07:19:41.55343566 +0000 UTC m=+864946.954686110: ☑️ agreed by YangKeao.
2023-06-30 03:04:17.569635461 +0000 UTC m=+54740.944213314: ☑️ agreed by hawkingrei.

This is an automated cherry-pick of pingcap#41056

c17ec7a

Signed-off-by: ti-chi-bot <ti-community-prow-bot@tidb.io>

ti-chi-bot mentioned this pull request Feb 12, 2023

planner: fix a bug when pushing streamAgg down #41056

Merged

12 tasks

hawkingrei added 3 commits February 13, 2023 13:14

fix conflict

042e1e4

Signed-off-by: Weizhen Wang <wangweizhen@pingcap.com>

update

3cbc94c

Signed-off-by: Weizhen Wang <wangweizhen@pingcap.com>

update

25c366a

Signed-off-by: Weizhen Wang <wangweizhen@pingcap.com>

ti-chi-bot added size/M Denotes a PR that changes 30-99 lines, ignoring generated files. and removed size/L Denotes a PR that changes 100-499 lines, ignoring generated files. labels Feb 13, 2023

*: bazel upgrade shard_count

e89fa52

Signed-off-by: Weizhen Wang <wangweizhen@pingcap.com>

ti-chi-bot requested a review from fixdb February 15, 2023 07:22

fixdb approved these changes Feb 15, 2023

View reviewed changes

ti-chi-bot added the status/LGT1 Indicates that a PR has LGTM 1. label Feb 15, 2023

ti-chi-bot added the cherry-pick-approved Cherry pick PR approved by release team. label Jun 29, 2023

ti-chi-bot bot removed the do-not-merge/cherry-pick-not-approved label Jun 29, 2023

ti-chi-bot bot deleted a comment from ti-chi-bot Jun 29, 2023

YangKeao approved these changes Jun 29, 2023

View reviewed changes

ti-chi-bot bot added needs-1-more-lgtm Indicates a PR needs 1 more LGTM. approved labels Jun 29, 2023

hawkingrei approved these changes Jun 30, 2023

View reviewed changes

ti-chi-bot bot added lgtm and removed needs-1-more-lgtm Indicates a PR needs 1 more LGTM. labels Jun 30, 2023

ti-chi-bot bot merged commit 96f648d into pingcap:release-6.1 Jun 30, 2023

ti-chi-bot removed the cherry-pick-approved Cherry pick PR approved by release team. label Jul 12, 2023

ti-chi-bot bot added the do-not-merge/cherry-pick-not-approved label Jul 12, 2023

ti-chi-bot added the cherry-pick-approved Cherry pick PR approved by release team. label Jul 12, 2023

ti-chi-bot bot removed the do-not-merge/cherry-pick-not-approved label Jul 12, 2023

ti-chi-bot deleted the cherry-pick-41056-to-release-6.1 branch April 15, 2025 08:09

Conversation

ti-chi-bot commented Feb 12, 2023

What problem does this PR solve?

What is changed and how it works?

Check List

Release note

Uh oh!

ti-chi-bot commented Feb 12, 2023 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

fixdb commented Feb 12, 2023

Uh oh!

Dousir9 commented Feb 13, 2023

Uh oh!

Dousir9 commented Feb 13, 2023

Uh oh!

ti-chi-bot commented Feb 13, 2023

Uh oh!

hawkingrei commented Feb 13, 2023

Uh oh!

ti-chi-bot commented Feb 13, 2023

Uh oh!

Dousir9 commented Feb 15, 2023

Uh oh!

Dousir9 commented Feb 15, 2023

Uh oh!

Dousir9 commented Feb 15, 2023

Uh oh!

fixdb left a comment

Choose a reason for hiding this comment

Uh oh!

YangKeao left a comment

Choose a reason for hiding this comment

Uh oh!

ti-chi-bot bot commented Jun 30, 2023

Uh oh!

ti-chi-bot bot commented Jun 30, 2023

[LGTM Timeline notifier]

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants

ti-chi-bot commented Feb 12, 2023 •

edited

Loading