Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

planner: prevent the optimizer from using different versions of stats of a table during optimization #50281

Open
qw4990 opened this issue Jan 10, 2024 · 0 comments
Labels
component/statistics epic/cardinality-estimation the optimizer cardinality estimation sig/planner SIG: Planner type/enhancement The issue or PR belongs to an enhancement.

Comments

@qw4990
Copy link
Contributor

qw4990 commented Jan 10, 2024

Enhancement

create table t (a int, b int, key(a), key(b));
insert into t values (1, 1);
analyze table t;  -- stats-ver1
set global tidb_stats_load_sync_wait=1;

-- restart TiDB
explain select * from t where a=1; -- load stats-col-a

explain select * from t where a=1 and b=1; -- load stats-col-b timeout
+-------------------------+---------+-----------+---------------+-----------------------------------------------+
| id                      | estRows | task      | access object | operator info                                 |
+-------------------------+---------+-----------+---------------+-----------------------------------------------+
| TableReader_7           | 2.00    | root      |               | data:Selection_6                              |
| └─Selection_6           | 2.00    | cop[tikv] |               | eq(test.t.a, 1), eq(test.t.b, 1)              |
|   └─TableFullScan_5     | 2.00    | cop[tikv] | table:t       | keep order:false, stats:partial[b:allEvicted] |
+-------------------------+---------+-----------+---------------+-----------------------------------------------+

In the second query, the optimizer uses 2 versions of statistics of table t where stats-col-a is loaded and then stats-ver1 is used while stats-col-b is not loaded and then pseudo is used, which seems risky.
Should we force the optimizer to always use one statistics version of a table during optimization? (all stats-ver1 or all stats-pseudo, no in-between state, not use them together).

@qw4990 qw4990 added type/enhancement The issue or PR belongs to an enhancement. sig/planner SIG: Planner component/statistics epic/cardinality-estimation the optimizer cardinality estimation labels Jan 10, 2024
@qw4990 qw4990 changed the title planner: forbid the optimizer to use different versions of stats of a table when optimization planner: prevent the optimizer from using different versions of stats of a table during optimization Jan 10, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
component/statistics epic/cardinality-estimation the optimizer cardinality estimation sig/planner SIG: Planner type/enhancement The issue or PR belongs to an enhancement.
Projects
None yet
Development

No branches or pull requests

1 participant