-
Notifications
You must be signed in to change notification settings - Fork 5.8k
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
*: implement the INSPECTION_SCHEMA to provide snapshot of inspection tables #14147
Conversation
…tables Signed-off-by: Lonng <heng@lonng.org>
Signed-off-by: Lonng <heng@lonng.org>
Signed-off-by: Lonng <heng@lonng.org>
@lonng please add some proper labels. |
Signed-off-by: Lonng <heng@lonng.org>
/run-all-tests tidb-test=pr/970 |
@@ -42,6 +42,8 @@ const ( | |||
PerformanceSchemaDBID int64 = SystemSchemaIDFlag | 10000 | |||
// MetricSchemaDBID is the metric_schema schema id, it's exported for test. | |||
MetricSchemaDBID int64 = SystemSchemaIDFlag | 20000 | |||
// InspectionSchemaDBID is the inspection_schema id, it's exports for test. | |||
InspectionSchemaDBID int64 = SystemSchemaIDFlag | 30000 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hard allocation code here should rebase autoID? if not, what if successive user creates schema/table with the same autoID.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
All id which allocated in SystemSchemaIDFlag
namespace will not conflict with tables created by the user.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
even if the same ID is used both in SystemSchemaIDFlag
and common table?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, the common table ID starts from 0 and will never conflict with the system table.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
See.
Signed-off-by: Lonng <heng@lonng.org>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
/run-all-tests tidb-test=pr/970 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
/run-all-tests tidb-test=pr/970 |
need fix the check dev and test first. |
/run-all-tests tidb-test=pr/970 |
/run-unit-test |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Approve
Signed-off-by: Lonng heng@lonng.org
What problem does this PR solve?
This PR introduces a new virtual system schema
inspection_schema
, which is used to provide a consistent view ofinformation_schema
tables, the related table will have the same table name withininformation_schema
. The data will be obtained lazily frominformation_schema
and cache inSessionVars
, and the cached data will be cleared atInspectionExec
closing.This PR is part of #13567
The reason why we should cache the data because some data of cluster-level memory tables will be retrieved many times in different inspection rules, and the cost of retrieving some data is expensive. We use the
TableSnapshot
to cache those data.What is changed and how it works?
TableSnapshot
, which represents a data snapshot of the table contained ininspection_schema
.inspection_schema
.information_schema
lazily and cache them.Check List
Tests
Release note
InspectionExec
executor lives.