Support information_schema.placement_rules

[morgo]

Support an information_schema table to summarize all placement rules.

Relates to #26582

[mjonss]

/assign @mjonss

[mjonss]

Looking at #26581 and #26580/#27574 I think the information_schema.placement_rules table have these columns (in additional to the ones mentioned here:

Column name	Content
RULE_ID	ID from meta storage / ID in placementpolicy.PolicyInfo
CATALOG_NAME	Until further support for catalogs, always "def"
POLICY_NAME	Name of placement rule (if not direct placement as table_options)
SCHEMA_NAME	Schema of the table using direct placement as table_options
TABLE_NAME	Table using direct placement as table_options
PARTITION_NAME	Partition using direct placement as table_options
CONSTRAINTS	Constraints affecting every copy (leader, voter, follower, learner)
LEADER_CONSTRAINTS	Constraints affecting the leader
VOTER_CONSTRAINTS	Constraints affecting voters
FOLLOWER_CONSTRAINTS	Constraints affecting followers
LEARNERS_CONSTRAINTS	Constraints affecting learners
SCHEDULE	Schedule of the placement rule {EVEN,MAJORITY_IN_PRIMARY}.
FOLLOWERS	Number of followers
VOTERS	Number of voters
LEARNERS	Number of learners

The INFORMATION_SCHEMA.PLACEMENT_RULES will not show the simplified syntactic sugar forms like PRIMARY_REGION or REGIONS, since that makes the table consistent and avoids having logic in the readers of this information schema.

Either RULE_NAME or a set of {SCHEMA,TABLE,PARTITION}_NAME will be set (the non set will be NULL, i.e. if there is a named PLACEMENT POLICY, it will have POLICY_NAME set and {SCHEMA,TABLE,PARTITION}_NAME all NULL, for a table with direct placement as table_options; POLICY_NAME and PARTITION_NAME will be NULL.

STATE will not be a part of the information_schema.placement_rules, since it may flip back and forth for a defined policy when tables/partition are added, instead it will be a part of SHOW PLACEMENT [FOR ...] command, which will give the state on global/database/table/partition level.

[xhebox]

The work could start, IMO. TableInfo now has realated info.

The INFORMATION_SCHEMA.PLACEMENT_RULES will not show the simplified syntactic sugar forms like PRIMARY_REGION or REGIONS, since that makes the table consistent and avoids having logic in the readers of this information schema.

From what we have done now, PRIMARY_REGION should be displayed. We don't have transformation from PRIMARY_REGION to XXX_CONSTRAINTS, but directly to the internal struct.

[mjonss]

The work could start, IMO. TableInfo now has realated info.

I have added PLACEMENT POLICY and DIRECT PLACEMENT for tables into my working branch: #27478
Have Schema and Partition level DIRECT PLACEMENT been implemented/merged too? Any hints on where to access it?

The INFORMATION_SCHEMA.PLACEMENT_RULES will not show the simplified syntactic sugar forms like PRIMARY_REGION or REGIONS, since that makes the table consistent and avoids having logic in the readers of this information schema.

From what we have done now, PRIMARY_REGION should be displayed. We don't have transformation from PRIMARY_REGION to XXX_CONSTRAINTS, but directly to the internal struct.

I think it would be more user friendly to transform PRIMARY_REGION/REGIONS to XXX_CONSTRAINTS so one can query the is.placement_rules table directly on the XXX_CONSTRAINTS columns, without having logic to also check PRIMARY_REGION/REGIONS.
Also including PRIMARY_REGION/REGIONS in the is.placement_rules would be OK, to show that syntactic sugar was used.

[xhebox]

Have Schema and Partition level DIRECT PLACEMENT been implemented/merged too? Any hints on where to access it?

No. I guess it will be in PartitionDef() and DBInfo.

I think it would be more user friendly to transform PRIMARY_REGION/REGIONS to XXX_CONSTRAINTS so one can query the is.placement_rules table directly on the XXX_CONSTRAINTS columns.

I could provide one, once #27814 is merged. I will leave the decision to you :)

[mjonss]

Have Schema and Partition level DIRECT PLACEMENT been implemented/merged too? Any hints on where to access it?

No. I guess it will be in PartitionDef() and DBInfo.

OK, then I will follow up on the github issue where it will be implemented. Possibly seeing if we can merge the work so far (having information_schema.placement_rules only covering PLACEMENT POLICY and DIRECT PLACEMENT for tables so far, and add DIRECT PLACEMENT for schemas and partitions later, when they are in place.

I think it would be more user friendly to transform PRIMARY_REGION/REGIONS to XXX_CONSTRAINTS so one can query the is.placement_rules table directly on the XXX_CONSTRAINTS columns.

I could provide one, once #27814 is merged. I will leave the decision to you :)

Yes, please provide a function transforming the syntax sugar to XXX_CONSTRAINTS, which would make it more user friendly to search in the information_schema.placement_rules table :)