I think they might be orthogonal.
It is all about sub-query.
On 2020/07/21 05:48:54, Danny Chan wrote:
> If it is only constant NOT IN predicate, how difficult it is to rewrite it
> into a normal composite AND predicate before entering the planning phrase ?
>
> Best,
> Danny Chan
> 在 2020年7月21
If it is only constant NOT IN predicate, how difficult it is to rewrite it into
a normal composite AND predicate before entering the planning phrase ?
Best,
Danny Chan
在 2020年7月21日 +0800 PM12:35,Haisheng Yuan ,写道:
> Thanks Jinpeng for providing a good example for not in subquery.
>
> I 100% agree
Thanks Jinpeng for providing a good example for not in subquery.
I 100% agree with you that correlated query won't be represented by ANTI_NOTIN
join type, and it is not the proposal's intention. Here what we are discussing
is not to use ANTI_NOTIN to represent all the NOT IN sub-queries, that is
Thanks for making this release available for voting, Chunwei!
Verified GPG Signature - OK
Verified SHA512 - OK
Ran tests per HOWTO (./gradlew check) - OK
Quickly skimmed release notes - Looks good, but I agree with Julian's
comments.
Spotted checked a few JARs in the Maven repository - OK
Envi
Hi.
In some SQL engine, the query
select * from A where c1 not in ( select c1 from B where B.c2 = A.c2);
is transformed to a plan like
select * from A LEFT ANTI JOIN B on A.c2 = B.c2 AND (A.c1 = B.c1 OR A.c1 is
null OR B.c1 is null);
Here, the "LEFT ANTI JOIN" is nothing more than traditional def
Environment:
Mac OS X 10.15.1, JDK 1.8.0_162
- Checked signatures and checksums, OK
- Ran unit tests (./gradlew build), OK
+1 (binding)
> * why is 4032 'breaking'?
With that change, the CalcMergeRule won't match PhysicalNode(including
EnumerableCalc) in VolcanoPlanner. Perhaps I should elabora
Downloaded, checked hashes, built and ran tests on Ubuntu/JDK 14;
checked distro against git (see issue 1); reviewed release notes (see
issue 2).
+1 (binding) but issues 1 and 2 need to be fixed right after the release.
Issue 1. License file is not the same as in source control:
diff -r ./LICENS
Stewart Bryson created CALCITE-4135:
---
Summary: Cannot find SqlDdlParserImpl class, which seems necessary
for parsing DDL.
Key: CALCITE-4135
URL: https://issues.apache.org/jira/browse/CALCITE-4135
Pr
Another quick thought as far as it concerns the IN operator would be to use
RexCall as it is right now where the first operand in the list is a
RexInputRef for instance and the rest are the literals.
I assume that taking this direction would need to change a bit the
respective SqlOperator.
I haven
Hi Taz,
If you are relying on the RelMetadataQuery [1] API then you may need to set
your provided into THREAD_PROVIDERS in a similar way that it is done in
RelMetadataTest [2].
Best,
Stamatis
[1]
https://github.com/apache/calcite/blob/7a462f2b2f78aa12068b691c1e423ea4c8a825e4/core/src/main/java/o
The name isn't very intuitive.
The concept of a list and a comparison operator seems OK. As Vladimir
points out, it is somewhat similar to RexSubQuery, so maybe this could
be a sub-class (but organizing the data a bit more efficiently).
I would be very wary of null semantics. RexNode scalar opera
How about making a sub-query type (in RexSubQuery), so it is gone
before we reach algebra.
ANTI_NOTIN is a terrible name. ANTI means 'opposite' to ANTI_NOTIN is
the opposite of NOT IN?!
On Mon, Jul 20, 2020 at 1:00 PM Haisheng Yuan wrote:
>
> Typo:
> We can just add a security guard saying that
Julian Hyde created CALCITE-4134:
Summary: Interval expressions
Key: CALCITE-4134
URL: https://issues.apache.org/jira/browse/CALCITE-4134
Project: Calcite
Issue Type: Sub-task
Rep
Typo:
We can just add a security guard saying that it is supported.
Should be
We can just add a security guard saying that it is NOT supported.
On 2020/07/20 19:57:34, Haisheng Yuan wrote:
> I am not sure I got your implication by "pollute". If you mean changes, yes,
> it requires some changes
Hi Pavel,
Not sure if I understand your question, does override
"SqlDialect.unparseCall" [1] provide an entry point to customize CAST
unparsing per dialect?
[1]:
https://github.com/apache/calcite/blob/master/core/src/main/java/org/apache/calcite/sql/SqlDialect.java#L442
-Rui
On Mon, Jul 20, 20
I am not sure I got your implication by "pollute". If you mean changes, yes, it
requires some changes in rules. Do we need to change enumerables? Not
necessary. We can just add a security guard saying that it is supported. Not
everyone requires the Enumerable operators to support everything. Mor
+1
Checked hash and signature and compiled and ran tests. Thanks Chunwei!
--
Michael Mior
mm...@apache.org
Le lun. 20 juil. 2020 à 11:41, Chunwei Lei a écrit :
>
> Hi all,
>
> I have created a build for Apache Calcite 1.24.0, release
> candidate 0.
>
> Thanks to everyone who has contributed to
Hi all,
I have created a build for Apache Calcite 1.24.0, release
candidate 0.
Thanks to everyone who has contributed to this release.
You can read the release notes here:
https://github.com/apache/calcite/blob/calcite-1.24.0-rc0/site/_docs/history.md
The commit to be voted upon:
https://gitbox
hi,
I am trying to figure out how to add custom logic for providing metadata to
nodes inside my adapter with no luck.
I have an implementation of my own RelMetadataProvider, as described in the
docs.
After looking around, i still couldn't find a way to use this provider in
the planning phase
- n
Jiatao Tao created CALCITE-4133:
---
Summary: Shouldn't trim fields when it's under Union
Key: CALCITE-4133
URL: https://issues.apache.org/jira/browse/CALCITE-4133
Project: Calcite
Issue Type: Bug
Currently SqlDialect.getCastSpec() is used to amend types to cast to for
different dialects and works during Rel to Sql conversion. That means it cannot
be used when unparsing SqlNode tree to a specific dialect. Does somebody know
was it made intentionally and would it be better to provide alter
>Do you know what is the impact on Enumerable implementation?
I guess there are plenty of options there.
The key question regarding RexListCmp is as we introduce a new Rex node,
all the planning rules and all engines
must support it somehow.
Technically speaking, we have RexSubQuery.
Haisheng, h
I have some concerns that this new type would "pollute" the existing Join
logic, rules and enumerable implementations.
Brainstorming: maybe we could consider it as a separate logical operator
(with its corresponding enumerable implementation)?
Le lun. 20 juil. 2020 à 06:08, Haisheng Yuan a
écri
23 matches
Mail list logo