Ruben Q L created CALCITE-4123:
--
Summary: Make EnumerableMergeJoin constructor protected
Key: CALCITE-4123
URL: https://issues.apache.org/jira/browse/CALCITE-4123
Project: Calcite
Issue Type: Ta
Haisheng Yuan created CALCITE-4124:
--
Summary: Stop invalidating metadata cache in VolcanoRuleCall
Key: CALCITE-4124
URL: https://issues.apache.org/jira/browse/CALCITE-4124
Project: Calcite
I
> Customized sql operator can also benefit. [1]
I am not sure if I missed something. Can you show me how can the customized sql
operator benefit from this?
e.g. geospatial operator intersect (it is input order insensitive):
boolean &&( geometry A , geometry B )
> Add a SqlOperator interface is n
I agree that extensibility might be helpful, however:
1) I do not like the idea of XOR-based hash code, because it would make
($1=$1) have the same hashcode as ($2=$2) and so on.
2) "$2 > $1 is reordered to $1 < $2, so that predicate a > b and b < a can
be reduced to a > b."
This reverting can ea
> 1) I do not like the idea of XOR-based hash code, because it would make
> ($1=$1) have the same hashcode as ($2=$2) and so on.
You have a point. However, is it really a concern? How frequent will it occur?
Especially when an operator like Join, Filter, that has the same input rel, but
with diff
> things might be bad if we want do dedup RexNode children using
Set
I guess it is exactly the action RexSimplify does currently :-/
https://github.com/apache/calcite/blob/3fb68f6c22a7bcbc4cb1fff114bc911b1e31c4de/core/src/main/java/org/apache/calcite/rex/RexSimplify.java#L1377-L1380
>The Join ope
> things might be bad if we want do dedup RexNode children using
Set
I guess the following might work better than XOR:
a) compute xor of the hashes
b) compute sum of the hashes
c) compute product of the hashes (with 0 replaced by 1 to avoid 0*n=0)
Then combine the three values somehow. For instan
The Apache Jenkins build system has built Calcite-Master (build #1837)
Status: Failure
Check console output at https://builds.apache.org/job/Calcite-Master/1837/ to
view the results.
> a) compute xor of the hashes
> b) compute sum of the hashes
> c) compute product of the hashes (with 0 replaced by 1 to avoid 0*n=0)
> Then combine the three values somehow. For instance: (a*17+b)*17+c
That is really good one. Better than pure XOR.
I also found this in scala:
https://github.com/
Guava library's approach is pretty naive:
Hashing.combineUnordered
It just adds each byte together, I don't think it is better than the one you
proposed.
BTW, I don't understand why we need c? Isn't a*17+b good enough to avoid the
corner case?
On 2020/07/15 20:33:55, Haisheng Yuan wrote:
> >
>BTW, I don't understand why we need c? Isn't a*17+b good enough to avoid
the corner case?
That depends on the number of corner cases we want to avoid :)
a*17+b might be good enough.
Vladimir
In answer to your question, no, Calcite does not support ENUM. It
looks as if only MySQL does this.
One idiomatic SQL way to achieve this would be to define a CHECK
constraint that ensures that a column can only have a given set of
values. Then hopefully a storage system would compress repeated va
Hi Julian,
Thanks for your answer. I dont know other dbs but Also Postgresql support
enum too[1]. Do you think supporting logical types makes more sense ? When
we define a new type that can be stored in a schema field. Is it possible ?
Thanks
[1] https://www.postgresql.org/docs/11/datatype-enum
Hi Talat,
I am guessing when you say logical type, you mean something like this in
Beam [1].
My question is why do you need Calcite to support ENUM? If you use logical
type, you can define a ENUM by yourself and the underlying type can be a
Map. Map is supported by Calcite. So ENUM will be transp
TL;DR: PMC members, would you vote for a release 1.24 if it includes
binary files necessary for testing?
I would like to include the InnoDB adapter [1] in release 1.24. It is
well written, well documented, and it is ready.
There is one problem: there are some binary files (in InnoDB format)
[2] t
Hi Rui,
Yes On the Beam side I am using Enum logical type. I thought I can use Int
sql type however i faced following issues.
Let assume my enum is [(0,Apple),(1,Orange),(2,Pears),(3,Banana)].
- If I map my Enum type to any calcite type. there can be other columns
which have the same sqltype. How
The Apache Calcite team is pleased to announce the release of Apache
Calcite Avatica Go 5.0.0.
Avatica is a framework for building database drivers. Avatica
defines a wire API and serialization mechanism for clients to
communicate with a server as a proxy to a database. The reference
Avatica cli
> I might be wrong, however, I did see "< vs >" normalization to reduce the
> search space. I added the normalization performance rather than aesthetics
> reasons.
Are you sure the performance gain is caused by "< vs >" normalization instead
of "=" normalization? Can you show me the test case?
>
Well, I think I now got your idea, I agree a specific operator sub-class plus a
special symmetric hash code is more efficient and extensible. But for the first
version, I would only consider binary operators because I could not figure out
how to implement an efficient equals for operator like IN
If the number of operands is greater than a threshold, like 5, or 10, we can
just stop normalizing it.
But currently AND/OR in Calcite is always binary operator, IN is not supported
in RexNode world.
Anyway, the discussion is orthogonal with your pull request, and it doesn't
block the proceedin
Rui Wang created CALCITE-4125:
-
Summary: Stream Join
Key: CALCITE-4125
URL: https://issues.apache.org/jira/browse/CALCITE-4125
Project: Calcite
Issue Type: Sub-task
Reporter: Rui Wang
Regarding CALCITE-4000, the PR should be ready to merge now. Thanks for all
the help from Feng, Danny and Chuwei!
-Rui
On Tue, Jul 14, 2020 at 11:11 PM Chunwei Lei wrote:
> Thank you for all your effort.
>
> Now there're only two issues(CALCITE-4000[1] and CALCITE-4118[2]) to
> be fixed in 1.2
+1
I am fine to make an exception for this release.
Let's see what's author's plan to remove the binary files in next release.
On 2020/07/16 00:02:26, Julian Hyde wrote:
> TL;DR: PMC members, would you vote for a release 1.24 if it includes
> binary files necessary for testing?
>
> I would lik
Haisheng Yuan created CALCITE-4126:
--
Summary: Stackoverflow error when applying JoinCommuteRule
Key: CALCITE-4126
URL: https://issues.apache.org/jira/browse/CALCITE-4126
Project: Calcite
Iss
I am +1 for including the files in this release as long as they are
removed in the next release.
Francis
On 16/07/2020 1:08 pm, Haisheng Yuan wrote:
+1
I am fine to make an exception for this release.
Let's see what's author's plan to remove the binary files in next release.
On 2020/07/16 00
IMHO If you need those files for tests and you don't have a way to generate
them it is allowed to keep them.
You can add some readme file that explain their nature. You can also add a
check sum file.
Just my 2 cents
Enrico
Il Gio 16 Lug 2020, 05:40 Francis Chuang ha
scritto:
> I am +1 for incl
Hey Chunwei!
about CALCITE-4118: I wanted to get back to it - but I was busy doing other
things...
The patch is not ready; it's wip branch is here:
https://github.com/kgyrtkirk/calcite/tree/4118-cast-varbinary
My plan was to figure out how to do it without writing down concreate
types(like CHA
>But currently AND/OR in Calcite is always binary operator
I guess we might want to add multi-arg AND in the future to address
AND(AND(AND(...))) issues.
I know IntelliJ IDEA switched to multi-arg "+" and similar representations
to reduce the complexity of certain operations.
PS. Even though we c
28 matches
Mail list logo
