search

risingwavelabs / risingwave

Best-in-class stream processing, analytics, and management. Perform continuous analytics, or build event-driven applications, real-time ETL pipelines, and feature stores in minutes. Unified streaming and batch. PostgreSQL compatible.
https://go.risingwave.com/slack
Apache License 2.0
7.09k stars 585 forks source link

use `ANALYZE` to update the cardinality property of a materialized view #11188

Open BugenZhao opened 1 year ago

BugenZhao commented 1 year ago

Does it possible to modify table scan cardinality after persisting? I mean if we fix some bugs or support cardinality estimation for more operators later, should we update the existing persistent cardinality?

I think it's possible but hard to be done automatically. 😕 Theoretically, this requires us to derive cardinality directly on the protobuf representation of plan nodes.

What if we have an Analyze statement? And only trigger these updates for Analyze🤔.

Yeah. The final cardinality should be deterministic as long as there's no correctness issue in the optimizer. So it seems we can always update the cardinality through the definition SQL of a materialized view at any time.

Originally posted by @BugenZhao & @chenzl25 in https://github.com/risingwavelabs/risingwave/issues/11151#issuecomment-1647678125

github-actions[bot] commented 5 months ago

This issue has been open for 60 days with no activity.

If you think it is still relevant today, and needs to be done in the near future, you can comment to update the status, or just manually remove the no-issue-activity label.

You can also confidently close this issue as not planned to keep our backlog clean. Don't worry if you think the issue is still valuable to continue in the future. It's searchable and can be reopened when it's time. 😄