Hi Andras,
Thank you for introducing yourself and dianemo DB to us.
Welcome to Calcite community and look forward to conference to know more about
your algorithm.
Thanks,
Haisheng Yuan
On 2021/05/27 16:59:00, András Gerlits wrote:
> Hello everyone,
>
> I've been asked by the Getting
Getting back to your window query example:
> Consider the Window function:
> SELECT
> AGG1 over (partition by a),
> AGG2 over (partition by b),
> AGG3 over (partition by c),
> ...
> FROM input
Window is quite special because the logical vs physical operator count is not 1
to 1,
Calcite does not support Oracle’s outer join syntax (“(+)”) or, for that
matter, SQL Server’s syntax (“(*)”).
Please log a JIRA case, asking for both to be added to the Babel parser. (I
don’t want to add it to the Core parser, because it will cause ambiguities.)
I don’t know of a workaround.
Hello Calcite Development Team!
I'm a software developer working on a project which includes Oracle SQL queries
parsing and transformation, and I'm using Calcite's engine to accomplish some
of my objectives.
I've been facing some issues regarding the parsing of SQL89 queries, more
>In distributed systems, an implementation rule may produce different
>physical operators depending on the input traits. Examples are Aggregate,
>Sort, Window.
No, in most cases, physical operators are generated regardless the input,
because the input traits are not know yet. Window
Hi, Vladimir.
Firstly, let me explain how the current solution handles your problems.
It is true that the current solution is not perfect. But it does solve most
problems. One thing to clarify is that, build rules are not necessary to
build all possible candidates. The key point is that parent
Hello everyone,
I've been asked by the Getting Started page on the Calcite website to send
a short introduction email about what I'm doing here.
I invented a new distributed transaction algorithm, upon which I've already
built an ACID CRUD database, which can currently be used via an API. I've
Jia Tao ~
The hints is production ready, we have implements many hints internal for
our Flink engine, such as the table hints and query hints.
The `RelBuilder#project` was modified to support hints already, one reason
for hints lost is that the projection are dropped for some reason(
maybe some
We did have some hints for our physical rules to apply some strategies, the
very common case is the JOIN algorithm, such as the NESTED_LOOP,
SHUFFLE_HASH, SORT_MERGE and so on.
The only reason that I do not implement the physical hints for Calcite is
that I do not have enough time for that,
Hi Jinpeng,
Thank you, I would try this approach with aggregates. But as I mentioned in
the previous email, it is not ideal, because we may generate wasteful
alternatives. This is so because we generate the physical nodes outside of
the optimization context: (1) we do not know what the parent
Hi Haisheng,
Thank you for your inputs. They are really helpful. Let me summarize your
feedback in my own words to verify that I understand it correctly.
1. In distributed systems, an implementation rule may produce different
physical operators depending on the input traits. Examples are
Hi
Indeed, there's some situation will lose hints, like RelBuilder#project, we
just construct a project without hints(ImmutableList.of()), so it will lose
hints too.
IMO, it's not ready for production, so finally, we give up this feature.
Currently, hints occurs some times in the mail list, proves
Hi，Vladimir. This could be a picture of how calcite optimize the two
aggregates problem:
step 1:
Without any hints for pruning, BOTH implementation of aggregations should
be built and held in memo.
For the top aggregation, the one-pass implementation requests a
HASH_DISTRIBUTED [a] distribution
xzh_dz created CALCITE-4624:
---
Summary: When query contains complex function, materialized view
recognition fails
Key: CALCITE-4624
URL: https://issues.apache.org/jira/browse/CALCITE-4624
Project: Calcite
14 matches
Mail list logo
