Our company (feldera.com) has built an incremental view maintenance engine 
using Calcite as a query parser and optimizer. While we maintain views 
incrementally very efficiently, we don't have a good optimizer that can detect 
whether a subquery is already materialized in an existing view, which is the 
problem that I understand you are tackling. So we could use this, but we are 
not actively working on this topic.

This looks to me like a fairly difficult problem.

As you can see from the bug reports, quite a few Calcite optimization rules 
have subtle corner cases where they do not preserve the query semantics. You 
have an even harder problem, of detecting whether two queries implement the 
same computation.

Mihai

________________________________
From: Christian Beikov <[email protected]>
Sent: Tuesday, August 13, 2024 10:01 AM
To: [email protected] <[email protected]>
Subject: Re: Support for mv rewrite between different join types

Hi,

I'd be very curious to see this being implemented. I wanted to tackle
this in the past as well, but was unable to properly understand the
papers in that area and hence failed to properly implement this. Nice to
see it being picked up again.

Regards,

Christian

Am 13.08.2024 um 18:50 schrieb suibianwanwan:
> Hello, everyone. As the use of materialized views is becoming more and more 
> widespread, it is believed that there will be more users of the materialized 
> view.
> Now including such as Oracle, Starrocks in the past on the basis of SPJG 
> rewriting gradually support the rewriting of different types of join, i.e. 
> SPOJG(o means outer join)
> I think we can build on UnifyRule by adding a rewrite between different join 
> types.
> I actually mentioned this PR about a year ago when I was new to calcite, and 
> didn't know enough about it then,  but now I think I'm ready to start over, 
> and before I do so again, I'd like to check out yours thoughts and 
> discussions!
>
> In addition, I just joined the dev list and apologize for asking questions 
> and discussion in jira issues in the past without understanding the community 
> rules, and thank you all for your help!
>
> Thank you,
> suibianwanwan

Reply via email to