There’s not very much difference between supporting IN in RexCalls vs.
supporting $HARD_IN in RexCalls. The distinction is important to me because I
think it’s important to have a “core” set of operators, and I don’t want to add
IN to that core. Stamatis feels differently, and I respect that.
In my opinion, we will need both - supporting IN operation (either through an
operator or an internal function) and adding support for building a balanced
tree. It’s always good to be resilient and capable of handling edge cases. The
IN support might require more work. Haisheng’s proposal is a
(Looping in the dev lists as suggested by Julian.)
Julian, Calcite community, let me know what you think about this option.
We're planning to host an Apache Ignite meetup with our group [1]
on November 13th or 14th in the San Francisco Bay Area. The desired topic
is the new Ignite SQL engine
Is there a possibility that data structures will be corrupted, if a thread is
interrupted in the middle of an operation?
Supposing that we allow resume, is it possible to safely resume after an
interrupt?
Supposing that we do not allow resume, and instead call close on the root
Enumerable, is
Your PR is a superset of the changes I made. Links to insecure pages
will not cause the problem that Julian experienced, only resources
which are requested when rendering the page (images, CSS, JS, etc.) I
still think we should fix any HTTPS links. Have you verified that all
the sites whose links
Adding IN RexNode only partially solves the problem, as it is still masking the
underlying issue. The fundamental reason for the stack overflow iies in the
left-deep binary tree. For queries that have tens of thousands of OR condition,
but not equals, which is not uncommon in our case, e.g.
(a
Make sense and quite reasonable.
- Haisheng
--
发件人:Stamatis Zampetakis
日 期:2019年10月08日 18:04:17
收件人:
主 题:[DISCUSS] Make Enumerable operators responsive to interrupts
Hello,
There are many use-cases which require
I fired CALCITE-3391 and its respective PR this morning.
@Michael: If your changes are sufficient then feel free to close the
respective JIRA/PR.
Best,
Stamatis
On Tue, Oct 8, 2019, 6:49 PM Michael Mior wrote:
> Pushed and this seems to have resolved the issue for me.
> --
> Michael Mior
>
Pushed and this seems to have resolved the issue for me.
--
Michael Mior
mm...@apache.org
Le mar. 8 oct. 2019 à 12:39, Michael Mior a écrit :
>
> Most of the warnings I see are like the below. Switching this to HTTPS
> should solve most of the issues. I'll make the change.
>
>
Most of the warnings I see are like the below. Switching this to HTTPS
should solve most of the issues. I'll make the change.
http://github.com/zabetak.png
--
Michael Mior
mm...@apache.org
Le lun. 7 oct. 2019 à 15:31, Julian Hyde a écrit :
>
> When I open https://calcite.apache.org/news/
>
Hello,
There are many use-cases which require stopping/cancelling the execution of
a query for various reasons. Currently, this can be done by launching the
query in a separate thread and then setting
DataContext.Variable.CANCEL_FLAG [1] accordingly.
However if the tread executing the query gets
>Definitely would simplify some of
>the RM steps for a release.
I've recently added GitHub Actions config to test Apache JMeter for Windows
and macOS.
So far I'm impressed.
Pros:
* It starts quite fast. Appveyor might take 2-3hours to even start the
build.
Actions start very fast, and it does
https://github.com/apache/calcite/pull/1489
On Mon, Oct 7, 2019 at 9:48 PM Julian Hyde wrote:
> I feel remiss in filling out
> https://calcite.apache.org/community/#upcoming-talks <
> https://calcite.apache.org/community/#upcoming-talks>. I’d be grateful if
> someone would remove ApacheCon NA
Did you intend to push this branch?
Julian
> On Oct 7, 2019, at 8:48 PM, danny0...@apache.org wrote:
>
> This is an automated email from the ASF dual-hosted git repository.
>
> danny0405 pushed a change to branch vvysotskyi-CALCITE-2018
> in repository
Hello Calciters,
in HerdDB community we are have recently upgraded Calcite to 1.21.0 but we
are getting feedback from downstream project about a bad problem with
subqueries with bind variables.
The issue is tracked as CALCITE-3347
https://issues.apache.org/jira/browse/CALCITE-3347
This is the
Stamatis Zampetakis created CALCITE-3391:
Summary: Insecure pages warning on Chrome
Key: CALCITE-3391
URL: https://issues.apache.org/jira/browse/CALCITE-3391
Project: Calcite
Issue
Hi Shubham,
In my understanding, same RelOptPlanner is the way to go, as one
VolcanoPlanner#registerMaterializations calls
RelOptMaterializations#useMaterializedViews and picks the best algebra
expression tree.
I'd suggest to create all the materializations into a
VolcanoPlanner and then
It might be better to add a proper IN operator in RexCalls instead of
something internal that does more or less the same thing.
It is true that adds more paths in the code and thus requires some
additional dev and further support but I think it is worth it.
Many people so far expressed an interest
18 matches
Mail list logo