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

*: Implementing information_schema.placement_rules #27478

Merged
merged 28 commits into from
Oct 15, 2021

Conversation

mjonss
Copy link
Contributor

@mjonss mjonss commented Aug 23, 2021

What problem does this PR solve?

Issue Number: partly close #26681, still missing Direct placement for Partitions (not yet implemented)

Problem Summary:

What is changed and how it works?

What's Changed:

How it Works:

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

  • Affects user behaviors
  • Contains syntax changes
  • Contains variable changes
  • Contains experimental features
  • Changes MySQL compatibility

Release note

information_schema.placement_rules lists all defined PLACEMENT POLICY and Tables with Direct Placement rules

But not filling it with correct data and columns are still not
fully defined.
@ti-chi-bot
Copy link
Member

ti-chi-bot commented Aug 23, 2021

[REVIEW NOTIFICATION]

This pull request has been approved by:

  • morgo
  • xhebox

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.

@ti-chi-bot ti-chi-bot added release-note Denotes a PR that will be considered when it comes time to generate release notes. do-not-merge/work-in-progress Indicates that a PR should not merge because it is a work in progress. size/L Denotes a PR that changes 100-499 lines, ignoring generated files. labels Aug 23, 2021
@github-actions github-actions bot added sig/execution SIG execution sig/sql-infra SIG: SQL Infra labels Aug 23, 2021
@ti-chi-bot 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 Sep 8, 2021
mjonss and others added 2 commits September 8, 2021 17:32
TODO: Schema level
TODO: Partition level
TODO: Add tests for privileges on Schema and Table level
@ti-chi-bot ti-chi-bot added size/L Denotes a PR that changes 100-499 lines, ignoring generated files. and removed size/M Denotes a PR that changes 30-99 lines, ignoring generated files. labels Sep 8, 2021
@mjonss mjonss marked this pull request as ready for review September 13, 2021 22:37
}
}
} */
if table.DirectPlacementOpts == nil {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we need to output the relationship between named placement policies and tables?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think that is what the SHOW PLACEMENT [FOR ...] is for. As I understand the requirements for information_schema.placement_rules is to find all definitions of placement rules, not necessary which objects are using the named policies. But I also don't know how you would get the full list of objects using a specific PLACEMENT POLICY.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's right - my intention in the proposal was to include those that have policies.

@xhebox xhebox self-requested a review September 22, 2021 08:06
@morgo morgo self-requested a review September 22, 2021 22:47
@ti-chi-bot ti-chi-bot added the needs-rebase Indicates a PR cannot be merged because it has merge conflicts with HEAD. label Sep 23, 2021
@ti-chi-bot ti-chi-bot added needs-rebase Indicates a PR cannot be merged because it has merge conflicts with HEAD. and removed needs-rebase Indicates a PR cannot be merged because it has merge conflicts with HEAD. labels Sep 23, 2021
Copy link
Contributor

@xhebox xhebox left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Rest LGTM

Comment on lines +2830 to +2831
// Get global PLACEMENT POLICIES
// Currently no privileges needed for seeing global PLACEMENT POLICIES!
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Whatever, the PR looks good to me. Maybe should merge it first.

For the problem, I think a new dynamic priv is enough. I could argue that there will be only one super DBA responsible for placement configurations, because only if you know all clusters can you schedule it better.

The problem only happens when there are two sets of settings, e.g. one in cn and another in us... But I think it can be effectively filtered using tricks like name: cn_policy_1.

@ti-chi-bot ti-chi-bot removed the needs-rebase Indicates a PR cannot be merged because it has merge conflicts with HEAD. label Oct 12, 2021
Copy link
Contributor

@xhebox xhebox left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I guess it is prepared since partition support is added.

@ti-chi-bot ti-chi-bot added the status/LGT1 Indicates that a PR has LGTM 1. label Oct 13, 2021
@ti-chi-bot ti-chi-bot added status/LGT2 Indicates that a PR has LGTM 2. and removed status/LGT1 Indicates that a PR has LGTM 1. labels Oct 15, 2021
@morgo
Copy link
Contributor

morgo commented Oct 15, 2021

/merge

@ti-chi-bot
Copy link
Member

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

Commit hash: a491ae5

@ti-chi-bot ti-chi-bot added the status/can-merge Indicates a PR has been approved by a committer. label Oct 15, 2021
@ti-chi-bot
Copy link
Member

@mjonss: Your PR was out of date, I have automatically updated it for you.

At the same time I will also trigger all tests for you:

/run-all-tests

If the CI test fails, you just re-trigger the test that failed and the bot will merge the PR for you after the CI passes.

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 ti-community-infra/tichi repository.

@ti-chi-bot ti-chi-bot merged commit 81c3013 into pingcap:master Oct 15, 2021
@mjonss mjonss deleted the is.placement_rules branch March 3, 2022 16:49
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
release-note Denotes a PR that will be considered when it comes time to generate release notes. sig/execution SIG execution sig/sql-infra SIG: SQL Infra size/L Denotes a PR that changes 100-499 lines, ignoring generated files. status/can-merge Indicates a PR has been approved by a committer. status/LGT2 Indicates that a PR has LGTM 2.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Support information_schema.placement_rules
7 participants