remove matviewgraph from pg_catalog.pg_matviews

[fuyufjh]

The matviewgraph field in pg_catalog.pg_matviews is very large. Consider removing it because in most cases the users do not care about it. Also, as a field introduced by RisingWave, it should be placed in rw_materialized_views rather than here.

Should the f.fragments be here? I think we have some rw_ system tables for that.

Yeah it’s added by ourselves. https://www.postgresql.org/docs/current/view-pg-matviews.html I tend to remove it.

Yeah. It should be inside rw_materialized_views instead or rw_fragments perhaps.
But cloud will still need some way to query for it.

[fuyufjh]

@arkbriar Can you please help to confirm this?

But cloud will still need some way to query for it.

We should use rw_catalog.rw_relation_info for querying fragments instead of pg_matviews.

[arkbriar]

@arkbriar Can you please help to confirm this?

But cloud will still need some way to query for it.

We should use rw_catalog.rw_table_fragments for querying fragments instead of pg_matviews.

Confirmed, it's used in a monitoring workflow. However, IIUC it can be safely ignored.

BTW, Is there any context for the question? I think the only thing that relies on the field is the portal. cc. @luotianchun for a double confirmation.

[luotianchun]

@arkbriar Can you please help to confirm this?↳

But cloud will still need some way to query for it.↳

We should use rw_catalog.rw_table_fragments for querying fragments instead of pg_matviews.↳

Confirmed, it's used in a monitoring workflow. However, IIUC it can be safely ignored.↳

BTW, Is there any context for the question? I think the only thing that relies on the field is the portal. cc. @luotianchun for a double confirmation.↳

Yes, portal need it to show the mview DAG. And hopefully there will not be any changes to the data structure.