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%
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
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
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
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
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
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
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
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]
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
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
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.
+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:
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
-
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:
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
>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,
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
Hi Haisheng,
Do you know what is the impact on Enumerable implementation? Will
RexListCmp still be converted AND/OR something else in that layer or there
will be new logic introduced to generate code for RexListCmp?
-Rui
On Sun, Jul 19, 2020 at 10:13 PM Enrico Olivelli
wrote:
> Il Lun 20 Lug
20 matches
Mail list logo
