Support logical view (CREATE VIEW commands)

[TennyZhuang]

Is your feature request related to a problem? Please describe.

Currently, RisingWave supports CREATE MATERIALIZED VIEW but not CREATE VIEW. It will be easier to generate some similar tests between logical view and batch view if we support it.

Describe the solution you'd like

Support CREATE VIEW.

Describe alternatives you've considered

As a first-class mview database, CREATE VIEW may be ambiguous, CREATE LOGICAL VIEW is also OK.

Additional context

[liurenjie1024]

I don't think we need a logic keyword to distinguish it from materialized view. The word materialized is used to distinguish it from logical one.

[xiangjinwu]

Rough idea:

• upon creation: generate logical plan
• store logical plan in catalog (requires serde of logical plan)
• upon use: get subplan similar to from-subquery
• similar checks as mview apply: (a) cannot have duplicated output column names; (b) cannot drop when being dependent on

[lmatz]

Currently, the create sink statement can only create from a materialized view with the following syntax as an example:

statement ok
create sink si
from
  s5 with (
    kafka.brokers = '127.0.0.1:29092',
    kafka.topic = 'sink_target',
    format = 'append_only',
    connector = 'kafka'
  )

Since there are many stateless ETL cases out there that may only want to sink the output to external systems, whether a materialized view should be created is an option up to users.

Also, some recent benchmarking results show that right now, having MV (even disabling the compactor) may introduce 30-40% overhead than not having MV in terms of throughput.

Is it possible to have improved results later? It is possible, but right now we can just disable MV to show better results than other streaming systems, which is critical in the near future.

In https://github.com/risingwavelabs/risingwave-test/issues/26, it is proposed that we can create sink from view. Syntax-wise, there are no changes to be made for create sink if we adopt this approach.

Once View is supported, we then can execute the query create sink from view with connector = 'blackhole' easily. For blackhole, I believe we just need to remove the MaterializedExecutor when generating the executable plan.

[lmatz]

Integration with dbt also requires the support of create view, right? @neverchanje

[xxchan]

As discussed offline (https://risingwave-labs.slack.com/archives/C034U0NH5ND/p1654588390981939), to support the functionality at the beginning, we choose to store the original SQL as a temporary solution. The main concern of storing logical plan is that we don't want to persist it because it may subject to change.

Some notes:

• We don't consider behavior under DDL now: If we can implement DDL correctly, the re-bind of the mviews is much harder than view. If we have some solutions to handle the mview, we can always apply it to view.
• At least the SQL should have been validated at the time of defining rather than time of using.

[fuyufjh]

Hi, any progress?

[lmatz]

feat(fe,meta): support logical view #6023

Approved in https://github.com/risingwavelabs/risingwave/pull/6023