Hi all, Dive into docs and I find the getJoinRowCount <https://calcite.apache.org/apidocs/org/apache/calcite/rel/metadata/RelMdUtil.html#getJoinRowCount(org.apache.calcite.rel.metadata.RelMetadataQuery,org.apache.calcite.rel.core.Join,org.apache.calcite.rex.RexNode)> seems the very thing I am looking for, I can reject the join when the rows are too many. Any ideas?
Yang Liu <whilg...@gmail.com> 于2020年2月17日周一 下午5:13写道： > Thanks Muhammad, can help give more detailed description? > Currently I have searched a RefOptCost, is this the one you are referring > to? > And I need to clarify, I do not mind the cost happened in datasources > since that will not affect my application, may just take a longer time to > get the result if the cost is high. > I care about the cost in our application and afraid of OOM. > > Thanks > > Muhammad Gelbana <mgelb...@apache.org> 于2020年2月17日周一 上午4:26写道： > >> If your only concern is about memory utilization, I would try estimating >> this using the plan's cost. But I guess you'll have run some tests to >> estimate the ranges you can accept. >> >> >> On Sun, Feb 16, 2020 at 5:50 PM Yang Liu <whilg...@gmail.com> wrote: >> >> > Is it possible to have some limitations on the SQLs to make sure our >> > application which depends on Calcite is "safe"? For example, when do >> merge >> > joining between 2 large datasources, our application maybe OOM since the >> > joining process is in memory. If we have the "limitation mechanism", we >> can >> > refuse to execute the joining to avoid OOM. >> > >> > Or we can only do the check outside Calcite? >> > >> > Thanks >> > >> >
