fix: remove matviewgraph column from pg_matviews

[fuyufjh]

I hereby agree to the terms of the RisingWave Labs, Inc. Contributor License Agreement.

What's changed and what's your intention?

Resolve #16070

Motivation: One of our customer run into frontend OOM because they issue a select * from pg_matviews every 10 seconds, while no one realized the size of matviewgraph column is so big that can cause frontend nodes to OOM.

Complete a long-time TODO in code:

risingwave/src/frontend/src/catalog/system_catalog/pg_catalog/pg_matviews.rs

Lines 40 to 42 in 254ad0c

	// Below are some columns that PostgreSQL doesn't have.
	// TODO: these field is only exist in RW and used by cloud side, need to remove it and let
	// cloud switch to use `rw_catalog.rw_relation_info`.

cc. @luotianchun As stated in the code above, please migrate to query rw_relation_info column fragments before v1.9 release.

Checklist

• I have written necessary rustdoc comments
• I have added necessary unit tests and integration tests
• I have added test labels as necessary. See details.
• I have added fuzzing tests or opened an issue to track them. (Optional, recommended for new SQL features Sqlsmith: Sql feature generation #7934).
• My PR contains breaking changes. (If it deprecates some features, please create a tracking issue to remove them in the future).
• All checks passed in ./risedev check (or alias, ./risedev c)
• My PR changes performance-critical code. (Please run macro/micro-benchmarks and show the results.)

• My PR contains critical fixes that are necessary to be merged into the latest release. (Please check out the details)

Documentation

• My PR needs documentation updates. (Please use the Release note section below to summarize the impact on users)

Release note

If this PR includes changes that directly affect users or other significant modifications relevant to the community, kindly draft a release note to provide a concise summary of these changes. Please prioritize highlighting the impact these changes will have on users.

[kwannoel]

Fyi issue should be resolved in the cloud side already https://linear.app/risingwave-labs/issue/CLOUD-2548/trigger-matview-sync-workflow-ondemand#comment-08f8258d. After this PR, the cloud side changes should just involve changing the catalog we query from.

Cloud side fix, which decouples poll mv query and get mv dag query.
https://github.com/risingwavelabs/risingwave-cloud/pull/6909/files#r1560435901.

[luotianchun]

cc. @luotianchun As stated in the code above, please migrate to rw_relation_info before v1.9 release.

@Gogomoe cc

[Gogomoe]

One of our customer run into frontend OOM because they issue a select * from pg_matviews every 10 seconds

For this issue, the cloud has a fix that query matviewgraph column on-demand. In the ongoing cloud release, we only query matviewgraph when the user expands the graph on the portal. The cloud release will be rolled out to PROD next Monday. So the issue will be resolved soon.

If we deprecate this field, portal folks need to find a other way to render the graph, It will take a while.

[yezizp2012]

One of our customer run into frontend OOM because they issue a select * from pg_matviews every 10 seconds

For this issue, the cloud has a fix that query matviewgraph column on-demand. In the ongoing cloud release, we only query matviewgraph when the user expands the graph on the portal. The cloud release will be rolled out to PROD next Monday. So the issue will be resolved soon.

If we deprecate this field, portal folks need to find a other way to render the graph, It will take a while.

Can cloud switch to rw_relation_info firstly? I will open a PR to add a new one, after that cloud can use that instead.

[kwannoel]

I think we should let cloud side migrate first to rw_relation_info first, before we deprecate matviewgraph field as per this PR.

[fuyufjh]

I think we should let cloud side migrate first to rw_relation_info first, before we deprecate matviewgraph field as per this PR.

I think we should merge this first. They have sufficient time to complete this before v1.8 release. As long as this PR gets merged, they can know how to adapt to the new version.