I also have this concern, a full build interrupts are awesome for hang on
/canceling the job, but it’s really hard to get it completely right, sometimes
confuses a lot for some code that should not care about these interrupts
signals.
Best,
Danny Chan
在 2019年10月17日 +0800 PM5:47，Vladimir
That is the point, we should supply a way to extend the RelMetadataQuery
conveniently for Calcite, because in most of the RelOptRules, user would use
the code like:
RelOptRuleCall.getMetadataQuery
To get a RMQ instead of using AbstractRelNode.metadata() to fetch a
MedataFactory.
We should at
TL;DR
Both top-down physical TraitSet request and bottom-up TraitSet
derivation have their strongth and weakness, we propose
on-demand TraitSet request to combine the above two, to reduce
the number of plan alternatives that are genereated, especially
in distributed system.
e.g.
select * from
liuzonghao created CALCITE-3427:
---
Summary: some subquery correlated case isn't fully implemented
Key: CALCITE-3427
URL: https://issues.apache.org/jira/browse/CALCITE-3427
Project: Calcite
xzh_dz created CALCITE-3426:
---
Summary: compensate validConstant type in RexLiteral.
Key: CALCITE-3426
URL: https://issues.apache.org/jira/browse/CALCITE-3426
Project: Calcite
Issue Type: Wish
I would be delighted if you would do that - thank you!
If you are organizing a meet up, please consult with this list. There may be
people who would be willing to speak and have something interesting to say.
Julian
> On Oct 16, 2019, at 3:14 PM, Jesus Camacho Rodriguez
> wrote:
>
> Hi
Haisheng Yuan created CALCITE-3425:
--
Summary: Inconsistent behavior of MetadataProvider in RelOptCluster
Key: CALCITE-3425
URL: https://issues.apache.org/jira/browse/CALCITE-3425
Project: Calcite
I wonder whether it is possible to add some kind of “action handler” to the
planner engine, called, for example, when a rule has fired and is registering
the RelNode created by the rule. People can write their own action handlers to
copy hints around. Since the action handlers are the user’s
Many people who are interested in Avatica are not interested in Calcite. (Yes
the Board are interested in both, because they are interested in the
communities, which overlap. But users of Avatica, not so much. And if people
perceive that Avatica requires Calcite they might be less likely to
MetadataFactory's implementation provides a unified, reflective approach to
retrieve metadata, no matter the metadata is builtin or extended type.
RelMetadataQuery provides convenient methods (in codegen) to get builtin
metadata, but not for costomized metadata. Unless we recommend sub-classing
Igor Guzenko created CALCITE-3424:
-
Summary: AssertionError thrown for user-defined table function
with array argument
Key: CALCITE-3424
URL: https://issues.apache.org/jira/browse/CALCITE-3424
At least in our project (Apache Ignite) we use AbstractRelNode.metadata().
But it so because there is no way to put our metadata type into
RelMetadataQuery without changes in Calcite.
Regards,
Igor
чт, 17 окт. 2019 г., 19:16 Xiening Dai :
> MetadataFactory is still useful. It provides a way to
MetadataFactory is still useful. It provides a way to access Metadata directly.
If someone creates a new type of Metadata class, it can be accessed through
AbstractRelNode.metadata(). This way you don’t need to update RelMetadataQuery
interface to include the getter for this new meta. Although
Since there's only one sub-project, why don't we convert the
Sub-Projects section on the homepage into a short description of
Avatica?
--
Michael Mior
mm...@apache.org
Le jeu. 17 oct. 2019 à 06:19, Francis Chuang
a écrit :
>
> This was one of the comments on the October Board report for Calcite:
Perhaps I'm missing something, but I don't see why this would be any
more efficient. Selecting all data is also not an efficient operation
in Cassandra. Using ALLOW FILTERING will likely be more efficient
since it's basically the same as doing a table scan, but it avoids
returning data which would
Wang Yanlin created CALCITE-3423:
Summary: Support using CAST operation and bool type value in table
macro
Key: CALCITE-3423
URL: https://issues.apache.org/jira/browse/CALCITE-3423
Project: Calcite
Thank for reply Michael.
yes i understood this on the documentation for example with "WHERE"
statement calcite i force the . "ALLOW FILTERING; "
and this can be expensive.
I think there may be an interesting approach using STREAM.
for example maintain a regular update between a cassandra
This was one of the comments on the October Board report for Calcite:
df: Great progress!
About Avatica - I had to google to find the subproject as I did
not see anything obvious on the Calcite site. I would also be
good to provide more status on the subproject in your
Roman Elizarov raises valid points re 'interrupts are too hard (or even
impossible) to get right':
https://twitter.com/relizarov/status/1184460504238100480
Vladimir
I agree with both points.
There are projects which do not handle interrupts in the best possible way.
My most recent experience was with H2 [1] where the database breaks
completely if a single thread is interrupted.
Best,
Stamatis
[1] https://github.com/h2database/h2database/issues/227
On Wed,
BTW, I think one JIRA number discussed in the thread would be
https://issues.apache.org/jira/browse/CALCITE-2855 not CALCITE-2885
Best,
Jin
XING JIN 于2019年10月17日周四 下午3:49写道：
> 1. RelMetadataQuery covers the functionality of MetadataFactory, why
> should we keep/maintain both of them ? shall we
1. RelMetadataQuery covers the functionality of MetadataFactory, why should
we keep/maintain both of them ? shall we just deprecate MetadataFactory. I
see MetadataFactory is rarely used in current code. Also I
think MetadataFactory is not good place to offering customized metadata,
which will make
22 matches
Mail list logo
